How to view the automatic proxy arps NGX

[Brentd]

Hi all,

Is there way to view the proxy arps that are created when you create automatic static NATs from NGX.

Even the NAT rule base is a pain regarding this because when the tool tips appear for the objects that are NATing you still only see the configured IP and not the NAT IP (which I thought would the most obvious way of displaying the object within the NAT rulebase)

Thanks
Brent

[northlandboy]

A/ Don't use automatic NAT.

B/ If you must use automatic NAT, "fw ctl arp" will show the firewall-configured proxy ARPs. Better is to check arp -a output on your firewall though, look for proxy ARP entries.

[kva.kva]

Originally Posted by northlandboy

A/ Don't use automatic NAT.

I don't agree, I try to use Automatic NAT where is possible. :)

[northlandboy]

Suit yourself, but when I've always found automatic NAT to be a pain, particularly once you have a complex network, with multiple layers of firewalls, automatic NAT will cause more problems than it's worth. You end up natting connections that don't need to be natted, and you have to put in manual rules above the automatic ones, to say "don't nat anything between these internal networks"

You also then have the issue of not having objects created with the NAT address, so you can't search for them in Tracker, and you can't see the NAT IPs in your objects list.

I don't really understand what the advantages of automatic NAT are - care to enlighten me? ;-)

[abusharif]

Originally Posted by northlandboy

I don't really understand what the advantages of automatic NAT are - care to enlighten me? ;-)

Lazyness ;-)

[kva.kva]

Originally Posted by abusharif

Lazyness ;-)

Simple truth :)

But once I have troubles with Edge connection with SC behind NAT. I cannot to established it without automatic NAT with option "Apply for VPN-1 Pro/Express control connections". May be this option is main necessity to use Automatic NAT.

[northlandboy]

Fair enough.

[BarryStiefel]

Originally Posted by northlandboy

Suit yourself, but when I've always found automatic NAT to be a pain, particularly once you have a complex network, with multiple layers of firewalls, automatic NAT will cause more problems than it's worth. You end up natting connections that don't need to be natted, and you have to put in manual rules above the automatic ones, to say "don't nat anything between these internal networks"

You also then have the issue of not having objects created with the NAT address, so you can't search for them in Tracker, and you can't see the NAT IPs in your objects list.

I don't really understand what the advantages of automatic NAT are - care to enlighten me? ;-)

I always recommend using Automatic NAT rule creation whenever possible. I'm even ready to say it's a "Best Practice". Here are the reasons I give:

1. Automatic NAT rule creation is much faster than Manual NAT rule creation. I can do it in about four seconds, rather than a couple of minutes.

2. Automatic NAT rule creation is almost foolproof. You configure it and it runs.

3. I think there are still issues with Manual NAT rule creation not doing the ARP replies properly.

4. With manually-created NAT rules, the "flyover" hints often give confusing information.

I use Automatic NAT rule creation in my classroom and I can configure six of them in about 30 seconds and they work perfectly every time.

Could you please provide the arguments for using Manual NAT rule creation? I'm eager to hear the other side of this and I might learn something.

I agree in advance that port translation may require Manual NAT rule creation and that my experience may be with fairly simple networks. I'm also now using R60 with HFA-04; they seem to have worked out all the automatic arp issues.

By the way, northlandboy, thanks for all your participation on the discussion board. You've been a really helpful member.

[Brentd]

One thing we have heard from our customers is that they wished there was a way to place manual rules between auto rules which always go to the top of the NAT rule base! this is not possible as far as I know. For this reason those customers are using manual NAT. However I agree with your other points!

Thanks

[chillyjim]

Originally Posted by Brentd

One thing we have heard from our customers is that they wished there was a way to place manual rules between auto rules which always go to the top of the NAT rule base! this is not possible as far as I know. For this reason those customers are using manual NAT. However I agree with your other points!

Thanks

You can place manual nat rules at the top and/or bottom of the nat rulebase.

There are some things (SIP/H.232 and some others) that only work with automatic nat.

[northlandboy]

Some random thoughts on why I prefer manual NAT, partly in answer to other points, partly just my ramblings, in no particular order:

* Automatic Proxy ARP - you may have had some success with it being configured automatically, but in my experience it causing nothing but problems. E.g. if you have a VRRP cluster, and hide NAT things behind the VRRP address. Reasonably common scenario, right? Except if you do it with a cluster, and automatically, the secondary node publishes a proxy ARP for the VRRP IP, causing all sorts of pain. ARP issues can take a little bit to track down sometimes too, particularly if an ARP entry is flapping. I've also seen it be unreliable too many times for my liking. "But it was working an hour ago..." The classic was where it would stop working, you would push policy, hey presto, it starts working again. Try explaining that to the people you've spent hours trying to convince that re-installing policy should not make any difference, since you're not changing policy.

* Related to the above, you should not really be configuring your networks to require proxy ARP anymore. It's 2006, not 1996. Route it. You should not have to touch the modules to add a new NAT. Different rant though.

* The time thing - it only takes me a couple of minutes to configure a manual NAT rule. An extra minute or two there, yes, but then I have an object I can filter on in Tracker, I can sort my object list to see what addresses I've got configured - rather than having to grep my objects_5_0.C to find which public addresses are used. In the NAT rulebase, I don't need to open an object, and change from the default screen, just to see what it's natted to - my tooltip tells me (aside - I love that feature!). An extra minute or two at setup is pretty much irrelevant to me, if it's going to save me a lot of time in future.

* Almost foolproof - perhaps you are right, but I take a slightly different tack - I would rather have people that know what they're doing, and take care with their work, than someone who can work a drag and drool interface.

* If you've got a medium network, with say a dozen clusters under that CMA, a few thousand objects, maybe several hundred NATs taking place on multiple firewalls, with some objects having two or more NATs on different enforcement modules - and this is a very realistic scenario, I've worked on multiple sites like this - then automatic NAT just doesn't cut it. Every automatic NAT shows up in every rulebase, regardless of whether that rulebase is installed on those modules or not. You just can't look through a NAT rulebase - but I guess perhaps you're not supposed to.

* As soon as you have multiple layers of firewalls, you get in the situation of having to have manual NAT rules - even if it's sometimes to negate NAT in certain situations - e.g. a rule at the top to say "don't nat anything internal->internal". So you then end up with a mixture of automatic and manual NATs. It starts to become a bit of a mess, as you can only put manual nat rules above or below all the automatic nat rules - you don't have granular control. Is that a good policy to have both manual and automatic NAT rules? I would say not, in general. I think it's better to have a standard and stick to it.

* If you've got a huge number of NAT entries, but the connections are only in one direction, you can configure the NAT rules in one direction only. This can vastly reduce the size of your rulebase (I've worked with policies with several hundred entries in the NAT table).

* Granularity is probably the biggest one for me - sometimes I only want a NAT to apply for a specific source/destination pair. This is one of the things I love about Check Point NAT - this sort of thing is extremely difficult to do with Cisco.

* If I configure two objects to automatically static nat to 1.2.3.4, do I get an error? I haven't actually installed a policy like this, but it definitely lets me define the objects, which is just wrong. At least if I try and do something similar with manual NAT, I'll get a warning when I create a new object with the same address as an existing one.


Oh and Barry - thanks. It keeps me thinking about stuff, and I learn a fair bit from it.

[RobertGraham]

May I second northlandboy? Manual NAT is sometimes very necessary.

Based on my experience with rulebases that are at least 75-100 rules in length, manual NAT is the way to go. In complex environments you need very specific NATing that the auto rules aren't designed for. I would add that effectively using groups in your NAT rules is a way to simplify the policy. This is a technique that a guy named Rick Centner and I developed at an organization we once worked at together.

It looks like this:

1. (Special one way NAT rule here for instance) blah -> blup
2. InternalNetworksGroup (ours had like thirty networks) - VPNnetworksGroup ORIGINAL for all other fields # FOR VPNs
3. VPNnetworksGroup InternalNetworksGroup ORIGINAL for all other fields #2 reversed
4. IntNetwork1 ANY HideIP1 ORIGINAL for all other fields #Internet access
5. IntNetwork2 ANY HideIP2 ORIGINAL for all other fields
.
.
.
20. IntNetwork17 ANY HideIP17 ORIGINAL for all other fields

This is a brief explanation that makes sense if you can imagine what I'm talking about. If you want a more specific information, please post.


Perhaps we can say that in *most* environments, it's best to use auto NAT for the KISS factor. In more complex situations (especially using Provider-1 you want to seriously consider using manual). Also, some of us are just real control freaks who live on UNIX and are used to being able to configure everything from how the CLI prompt looks to which type of clock(analog or digital) is shown on the desktop.

[BarryStiefel]

Originally Posted by northlandboy

Some random thoughts on why I prefer manual NAT, partly in answer to other points, partly just my ramblings, in no particular order:

* Automatic Proxy ARP - you may have had some success with it being configured automatically, but in my experience it causing nothing but problems. E.g. if you have a VRRP cluster, and hide NAT things behind the VRRP address. Reasonably common scenario, right? Except if you do it with a cluster, and automatically, the secondary node publishes a proxy ARP for the VRRP IP, causing all sorts of pain. ARP issues can take a little bit to track down sometimes too, particularly if an ARP entry is flapping. I've also seen it be unreliable too many times for my liking. "But it was working an hour ago..." The classic was where it would stop working, you would push policy, hey presto, it starts working again. Try explaining that to the people you've spent hours trying to convince that re-installing policy should not make any difference, since you're not changing policy.

* Related to the above, you should not really be configuring your networks to require proxy ARP anymore. It's 2006, not 1996. Route it. You should not have to touch the modules to add a new NAT. Different rant though.

* The time thing - it only takes me a couple of minutes to configure a manual NAT rule. An extra minute or two there, yes, but then I have an object I can filter on in Tracker, I can sort my object list to see what addresses I've got configured - rather than having to grep my objects_5_0.C to find which public addresses are used. In the NAT rulebase, I don't need to open an object, and change from the default screen, just to see what it's natted to - my tooltip tells me (aside - I love that feature!). An extra minute or two at setup is pretty much irrelevant to me, if it's going to save me a lot of time in future.

* Almost foolproof - perhaps you are right, but I take a slightly different tack - I would rather have people that know what they're doing, and take care with their work, than someone who can work a drag and drool interface.

* If you've got a medium network, with say a dozen clusters under that CMA, a few thousand objects, maybe several hundred NATs taking place on multiple firewalls, with some objects having two or more NATs on different enforcement modules - and this is a very realistic scenario, I've worked on multiple sites like this - then automatic NAT just doesn't cut it. Every automatic NAT shows up in every rulebase, regardless of whether that rulebase is installed on those modules or not. You just can't look through a NAT rulebase - but I guess perhaps you're not supposed to.

* As soon as you have multiple layers of firewalls, you get in the situation of having to have manual NAT rules - even if it's sometimes to negate NAT in certain situations - e.g. a rule at the top to say "don't nat anything internal->internal". So you then end up with a mixture of automatic and manual NATs. It starts to become a bit of a mess, as you can only put manual nat rules above or below all the automatic nat rules - you don't have granular control. Is that a good policy to have both manual and automatic NAT rules? I would say not, in general. I think it's better to have a standard and stick to it.

* If you've got a huge number of NAT entries, but the connections are only in one direction, you can configure the NAT rules in one direction only. This can vastly reduce the size of your rulebase (I've worked with policies with several hundred entries in the NAT table).

* Granularity is probably the biggest one for me - sometimes I only want a NAT to apply for a specific source/destination pair. This is one of the things I love about Check Point NAT - this sort of thing is extremely difficult to do with Cisco.

* If I configure two objects to automatically static nat to 1.2.3.4, do I get an error? I haven't actually installed a policy like this, but it definitely lets me define the objects, which is just wrong. At least if I try and do something similar with manual NAT, I'll get a warning when I create a new object with the same address as an existing one.


Oh and Barry - thanks. It keeps me thinking about stuff, and I learn a fair bit from it.

Hello northlandboy,

Thanks for a great post. These are indeed good arguments. I think my experience has been limited to fairly small, simple configurations. I think I agree with you that on large, complex configurations, Manual Rule Creation might be best.

[Brentd]

This is most informative, thanks...

One thing, Northlandboy has said, you should not really be configuring your networks to require proxy ARP anymore. It's 2006, not 1996. Route it....?

Northlandboy, I am a little lost by this statement... (maybe my ignorance). i would expect if you had a private network range in your internal networks incl the DMZ, and you are expecting inbound connections to get to a DMZ host based on an external IP address, how can you route to it without having a proxy arp? Are you suggesting PATing for all of the connections inbound?


Thanks

[northlandboy]

OK, let's assume you've got a very simple firewall setup, with 3 connections - internal network, DMZ, external interface.

You have some say a mail server sitting in the DMZ. Both the DMZ and the internal network are privately addressed. You want to make the mail server publicly visible. Historically, you would have had a public network - let's say a /24 - on your external interface. You would have assigned an address from your public range to the mail server NAT.

Your problem then is that you need to get the packets addressed to the mail server NAT to be sent to the firewall's MAC address, so that it will process and NAT the packets. So to do that, you put a proxy ARP entry on the firewall, telling it to proxy ARP for the firewall. If you're particularly fond of doing things the hard way, you'll also have translate on client side unchecked, so you need to go and add a /32 route also.

That is all a lot of manual work. Also think about how you're going to deal with expansion - what if you use up all of that /24? Some people do even more crazy stuff like adding a secondary public interface to the firewall, and then doing proxy ARP for that.

Consider instead a different scenario. This time, you have a very small (say /29) public or private range between the firewall and the upstream router. Public if you need to do any VPNs, private otherwise. You still have the same /24 assigned for use as NAT addresses. This time, you add a route on the upstream router, telling it that in order to get to that /24, go via the firewall.

Now when the upstream router receives packets for your mail server IP, it knows it needs to route them to the firewall. It will set the firewall MAC as the destination MAC on the frames, and they will be forwarded correctly to the firewall. The firewall will process the packets, realise it needs to NAT it, do the NAT, and forward the frames to the destination.

This is a much cleaner way of doing it. Your NAT range doesn't physically exist anywhere. You can now use every address in that range. Far less manual work is required. If you need to expand the range, it's easy to just add a route to the upstream router for your new network.

The first method is a bit of a historical thing, but if I was setting up any new network now, I would have to have an extremely good reason for designing it in a way that required proxy ARP. Obviously there are some legacy systems where you can't easily move away from it, but you should not be deploying new systems requiring it.

As a side note, in the first case, rather than adding a proxy ARP to the firewall, you could have just added a /32 route to the upstream router - it would achieve the same outcome, of getting the router to forward those frames to the firewalls MAC address.

[RobertGraham]

Can you map this out with addresses better? Because as written here, it doesn't make sense to me.

The one external network is directly connected to the upstream router. The small private or public /29 network isn't yet relevant to the upstream router because it's looking for a NATed IP in the /24 segment.

I'm sure this works - I just don't understand how it works or even how to replicate it in the lab to test and learn.

[northlandboy]

Sorry if I wasn't clear enough, let's try again with some numbers punched in.

The key thing here is that the /24 network we're using for NAT doesn't physically exist anywhere - it's not going to be directly connected to the upstream router - it's not going to be configured on any device at all, it only exists virtually.

So, with some addresses, for the case where you would use proxy ARP:

* Assume our DMZ address range is 172.16.0.0/24. FW is .1, mail server is .2.
* Our public address range is 200.100.50.0/24. Upstream router is .1, FW is .2, and we're going to use 200.100.50.3 as the NAT for our mail server.
* For the sake of simplicity, we'll assume the upstream router has a default route to the Internet out its WAN link, and the only other network it knows about is the directly connected 200.100.50.0/24.
* To get this to work, we would add a proxy ARP on the firewall for 200.100.50.3, mapping to the firewall's MAC.

This way, when a packet from the Internet wants to get to your mail server (200.100.50.3), it gets routed to your upstream router, which knows that 200.100.50.0/24 is directly connected. Since it thinks it's connected, it sends out an ARP request for 200.100.50.3. The firewall responds, saying hey that IP address maps to this MAC address. The router then sets the destination MAC address on the frame to be the firewall, and puts the frame on the wire.

The firewall's NIC sees that frame, recognises the destination MAC, so it processes the packet. On the way up the stack, Check Point steps in, sees that it needs to NAT it, and it NATs 200.100.50.3 to 172.16.0.2, and forwards the frame.

All OK. Except we had to configure proxy ARP. And what happens if we've used up all of our /24 NAT range? What do we do then?

So here's an alternative design:
* Same DMZ range as before
* Same NAT range - 200.100.50.0/24 as before.
* This time though, we're going to use 192.168.1.0/30 as our network between the firewall and the upstream router. The upstream router will use 192.168.1.1, and the firewall 192.168.1.2.
* 200.100.50.0/24 is not configured on any device.
* Now we're going to add a route on our upstream router like this:
ip route 200.100.50.0 255.255.255.0 192.168.1.2
i.e we are telling the upstream router that to get to that public network, go via the firewall. Obviously you need to configure your upstream router to redistribute this route into BGP, or however you're letting the further upstream routers know where 200.100.50.0/24 is.
* Within Check Point, your NAT rule looks the same - NAT 200.100.50.3 to 172.16.0.2.

Now what happens when my server on the Internet wants to connect to your mail server? BGP routing tables will get it to your upstream router. Your upstream router knows that to get to that network, it goes via 192.168.1.2. So it sends out an ARP request for 192.168.1.2, the firewall responds, and the frame is put out on the wire.
Just like in the first case, the firewall will pick up the frame, since it has the firewall's destination MAC. It will look at it, realise it needs to NAT it, do that, and forward the packet to 172.16.0.2.

So we've achieved the same thing - we got the firewall to pick up a frame addressed to 200.100.50.3 off the wire, and NAT it. The difference is that we haven't had to do any proxy ARP configuration. And now think about what happens if we run out of space, and we get 200.100.51.0/24 assigned to us? We can just add a /24 route (more correctly, change the previous one to a /23) to the upstream router for that network. No further configuration required.

Note that you may wish to assign a public range to the network between your firewall and upstream router if you wish to do encryption. (Not so necessary at NGX though). You will also note that 200.100.50.1 and .2 are now available for use as NAT addresses, no longer being used for the router and firewall.

As a side note, in the first scenario, if you added a route like this to the upstream router:
ip route 200.100.50.3 255.255.255.255 200.100.50.2
that would override the connected route, and the router would forward those frames to the firewall's MAC. You wouldn't then need to configure a proxy ARP.

If you understand routing, and mac/IP translation, and layer 2 forwarding, it all comes together. You just need to think about what the point of proxy ARP is - it's purely to get those frames forwarded to the firewall. Once Check Point gets hold of them, it can deal with the NATting. Until you either route or proxy ARP for them though, the upstream router isn't going to forward them.

Am I making sense, or have I just made things worse?

[melipla]

Originally Posted by chillyjim

There are some things (SIP/H.232 and some others) that only work with automatic nat.

I'm a manual NAT person, however this might explain some of the weirdness I'm seeing with my H323 traffic [as it relates to NAT]. Can you elaborate or point to any documentation regarding this?

Thanks!

[Brentd]

Very Very Clear.....

I had not thought about the upstream router. This is where I was going wrong!

Thanks (Northlandboy) for all the effort you went to, in answering this.
Brent

[RobertGraham]

The proxy arp part was already a gimme, done that a million times.

The routing NAT part, now that's a very interesting solution. Once you put the networks in, and I know what network is getting NATed, which one is being routed, etc it all becomes clear.

That's a rather elegant solution that doesn't require any layer 2 configuration - excellent. I like it.

Very slick indeed. Did you invent this yourself or where did you learn about this?