How to view the automatic proxy arps NGX

[chillyjim]

Originally Posted by melipla

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!

I only heard about this because someone in support told me. I'm sure it's documented somewhere (the whole VoIP documentation from CHKP makes my head hurt).

If you are doing ANYTHING that even looks like VoIP you need to be on R60+HFA2+VoIP Hotfix 1 (2 is comming I'm told).

[northlandboy]

I certainly won't lay claim to coming up with it. When I first started doing serious work with Check Point, it was on a network that had been very recently designed and deployed. This was around FP2 days. There wasn't much natting taking place on the other 4.1 systems I'd seen up until then.

The design of that network worked like that - private subnets to the external interfaces of the firewalls, and routes on the upstream routers for out NAT pools.

So since I started out working with that, I just assumed that that was how it always worked. Conceptually, it seemed very simple and obvious to me. It was only later I came across proxy ARP scenarios, and it just didn't make much sense to me. I couldn't see the point in configuring proxy ARPs, and having those addresses in front of the firewall. Far better to make them virtual I thought.

I think that it should be made clear in the documentation that this is a valid network setup - the docs tend to talk about proxy ARP. Particularly for big networks where you do a lot of NAT, the ability to just route another network for expansion is tremendously useful.

[chillyjim]

FWIW I think Barry should reference northlandboy's design as a CPUG best practices. I do this a lot with my big hosters (the NAT addresses only exist inside the Check Point gateways) and it save a lot of problems (once you wrap your head around it that is).

[BarryStiefel]

Originally Posted by chillyjim

FWIW I think Barry should reference northlandboy's design as a CPUG best practices. I do this a lot with my big hosters (the NAT addresses only exist inside the Check Point gateways) and it save a lot of problems (once you wrap your head around it that is).

Sounds good to me.

[abusharif]

This is good setup, but not to forget, you would need access to the router or friendly ISP to configure the routing on the upstream router, which unfortunately is not always possible due to uptight people handling them.

[donshoutarp]

Hey Northlandboy,

I've done (and still do) similar things. I've also configured the upstream router to do all of the NAT'ing. One thing I've always struggled with is how to configure VPNs in this situation. More specifically creating gateways. With the real gateway having a private address, I've generally created "virtual" gateways with the public address. It seems to be kind of messy to do it this way. I also create a "virtual" CP management server and log server if necessary.

It gets really messy when there are two ISPs.

Do you have any thoughts on a best practice for this?

[veste]

Originally Posted by abusharif

This is good setup, but not to forget, you would need access to the router or friendly ISP to configure the routing on the upstream router, which unfortunately is not always possible due to uptight people handling them.

this came also into my mind, while reading the thread.

@northlandboy:
could you explain, how to solve this issue with "your" method, if i have an router from my isp with a public ip-address and no access to this router. do i need another router inbetween fw and isp-router?
what do i do, if i have 2 internet links? can i replace ISP-redundancy somehow?

thx,
stefan

[RobertGraham]

After reflecting on this and speaking with a colleague about it, I've become convinced that it's best to use a separate but smaller network(/28 or /29) for the segment between the CPE router and the enforcement point.

I know that in the past it was necessary to be very frugal with IPs, but between NAT, CIDR, and IPv6 on the way it shouldn't be such an issue. Incidentally, there are quite a few networks that haven't yet been assigned and several more that could be VLSMed.

I guess it's because I feel like: after the firewall it's the Internet and private addresses shouldn't be used on the Internet. (I know ISPs use 1918 IPs for their backbones which are definitely part of the Internet, but I'm not talking about that.)

[northlandboy]

Yes, I agree with Rob. I have done this in the past with privately addressed firewalls, but we ended up publicly addressing them, to deal with issues around VPNs.

It's not such an issue with NGX, but it can still cause problems.

Yes you do need either access to the upstream router, or understanding admins.

If you've got multiple ISPs, then I don't know how you deal with NATting issues anyway, unless you're doing it in a proper, serious way, and you've got your own transferable address block that you advertise via BGP. I haven't looked into how you deal with it with Check Point ISP redundancy.

Just to put this into context, remember that most of my experience is with reasonably large networks, where we do control the routers, and we do have our own address blocks. I don't really do much work with small setups. If you've only got a couple of public addresses, it doesn't really matter which way you do it. I'm more dealing with situations where NAT is used to control routing - i.e. to direct certain sorts of traffic via certain clusters. It's actually not all that often I do NAT for Internet-accessable systems. You're often NATting a third party to something in your network, so your systems can route to it, and then on the way out the firewall, you nat the source, so the vendor routes back to you.

In those situations, scalability, and ease of deployment are critical, which is why it is simply not practical to be configuring proxy ARP (or even worse, host routes) for every NAT you do. Nor would it scale.

I'm just looking back over this thread, and I see we've drifted a fair way from Brent's original question - but no problem, this is a good discussion! At least we answered the original question though ;-)

- Lindsay

[eduardoxmunoz]

Hi all!

thaks Northlandboy for share your experiences whith us...

One more question regarding ARP: I have configured diferents Clusters (HA & LB). The virtual MAC asigned to each virtual interface is a multicast MAC address. When define Manual NAT, which MAC address I should be configure? The physical MAC in each gateway or the virtual MAC? Any others consideration in ClusterXL configuration regarding ARP.

Thank You

[northlandboy]

The virtual MAC. Think through the implications of it.

[eduardoxmunoz]

Originally Posted by northlandboy

The virtual MAC. Think through the implications of it.

Yes, My question is because I made a manual static NAT in a ClusterXL with HA, I configure the virtual MAC associated with the public server IP address but it didn't work. When I change the virtual MAC for the physical MAC address in each gateway all works fine, however I could not probe if the Cluster works fine because the firewalls are in production enviroment.

[northlandboy]

If you're using multicast MAC addresses, then you may need to update your nexthop devices with static ARP entries.

You should be using the virtual MAC so that if the primary node fails, the other node will start accepting traffic destined to that MAC, and the surrounding devices will not notice any change.

If you use the real MAC address of each node, what is to stop the secondary responding to ARP requests? And if the primary fails, then all surrounding devices will need to update their ARP caches before traffic will start flowing through the secondary.

[Webcam007]

I must confess I was on here looking for an answer about a problem I'm having with Auto Nating. We've always used Manual Natting in the past but then swapped up to an Active/Passive cluster and were having major problems with re-ARPing the manual ARPs in the event of failover.

Consequently we have been labouring long and hard to swap across to Auto Arps but I have had problems with devices in our external DMZ being Natted behind the external Virtual address when they talk inbound to our network. I thought CheckPoint would be intelligent enough to work out that it shouldn't do this by looking at its Topology but either I've got something wrong or its not as clever as I first thought. The only way I've found round it is to put a Manual NAT further up the rulebase saying don't NAT inbound but that seems a bit rubbish!

However with this new solution we would not have to worry about using Auto NATs and can go back to the much more configurable Manuals.

Thank you very much for this Gem of information.

Wish I'd read it about 3 months ago!!!!!!!

Regards

Webcam007

[dav_y2k]

Hi,
I'm a newbie to checkpoint and I found this post almost similar to what I'm trying to do. Here is my scenario:

I have a Win2k running R55 with 3 interfaces Eth0-->Ext, Eth1-->LAN, Eth2-->DMZ it also has a Win2k RRAS (site-to-site VPN) as well all is working fine (but we need to install R62 on a Win2k3 coy policy).

When I install the same policy on the R62 running Win2k3 server the LAN can connect to the internet but can't ping the mail and web server that is being NAT'd do I have to configure proxyarp.

I checked the logs but can't find any thing wrong. the VPN server says verifying username & password then says the server did not respond on time. but when the old firewall is connected it connects and works perfectly.

thanks for your response.

[Brentd]

Just as a test can you get a host that is on the same subnet as your external to arp for the ext proxy arp address? then check the hosts arp cache to see if the configured proxy arp is setup correctly? This could help you solve where the problem lies. I have done almost this exact same thing with R60 and it works great?