Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hide NAT Using NG FP2 and Linux

Status
Not open for further replies.

Moss2001

IS-IT--Management
Aug 23, 2001
17
0
0
GB
Hi!

Wonder if anyone is able to provide us with some assistance.

We have installed FW1 NG Feature Pack 2 on Red Hat Linux 7.1 as provided by Checkpoint. We are experiencing problems getting Hide Nat working. We want our internal network to have their addresses NAT'd before going out on the internet.

Using the Automatic NAT Configuration for the internal network object will work fine if we select the NAT address as being the IP address of the external NIC on the firewall.

However, this is not best practice so we want to use another valid internet address to hide behind, but when this is set all external traffic fails-although the firewall log file shows the outgoing packet as accepted ok.

We have a suspicion that this is to do with either ARP tables, Routing tables or both and have added manual arp entries to map the hide nat address to the mac address of the external adapter but still nothing!

Any ideas anyone??
Chris Vickers
moss2001@hotmail.com
 
Hey Moss,

Its been a couple weeks since you posted, so just in case you haven't found the soultion yet...
I ran into a similar problem with using a static hide on a RH Linux 7.2 machine running FW-1 FP2.

In order for NAT to work under Linux you have to do 3 things manually
1.First is manually create the NAT entry in FW-1's policy editor (I've heard you can use the auto NAT feature, but I couldn't).
2.Next you need to create a static arp entry (I've used a nice little app called tarpd (you can get that at 3.Finally you need to add a route on the Linux FW box, pointing to the NATed workstation. The route should be to the PUBLIC IP address using the PRIVATE IP of the workstation as the gateway.

If you skip step 3, everything will "look" like its functioning properly, but if you use a packet sniffer on the firewall, you'll see that the FW is actually sending an ICMP redirect packet, because the FW does NOT know how to route to the the NATed workstation.

So those are the three things you need to do if you are NATing workstations behind the FW, if the translated address is NOT the external interface on the firewall.

This of course applies to Linux only, as implementations on windows platforms allows automatic arp, and also automatically adds routes (using the checkbox "translate destination on client side")
These options are found in the NAT section of the Global Properties.

Hope this helps!
 
Thanks for that-to be honest we had already sorted it and I've been meaning to post a follow up on here but just never got around to it!

After much digging I found a forum somewhere (can't remember where exactly-I'll post it when I'm back at work on Monday) where it was generally agreed that the Automatic ARP configurationon the Global Properties on SecurePlatform NG FP2 did not work at all. I can verify that in our case it definitely did not!!!

But even though we had created this manually we still had problems. So we went through everything again from scratch and found the following-(which is pretty much what you have suggested already but here goes anyway!!)

1) There was a host route missing for the non-existent external address to the internal adapter of the firewall.

2) Even if an arp entry is created manually it will need to be re-created upon a reboot-Being 100% Linux newbies this caused us a big headache!! In the end we added the arp -s command to the network startup file that runs when the machine starts up.

3) Silly really-but when all the above was correct we still had problems. I suddenly realised that because we had set up NG on new hardware our Cisco router would still have the MAC address of the old firewall for the non-existent IP address in it's arp cache! A quick call to Worldcom to get the arp cache cleared and it all burst into life!!!

And thats it really-So thanks for your reply. It's good to know that there are other people out there that have had similar problems and it's not just us going around in circles.

Just to let you know also that in our case the automatic NAT rules for the internal network worked fine (as long as the above was set correctly). But we still had to add a rule where no translation occurs between our VPN-but thats another story!!

Thanks again-and maybe these (long!) posts will help someone else that comes across this problem!!!!

Cheers!
Chris Vickers
moss2001@hotmail.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top