VPN problem across CheckPoint FW

[Jpeanut]

I'm having a problem reaching a IP address through my Cisco 3000 VPN setup. Here's what it looks like

HomeUser(192.168.0.x NATs 24.234.x.y)-->VPN Client(DHCP 172.17.x.y)-->Firewall(NATs 192.168.10.5)-->Router(147.146.x.y)

I cannot reach 147.146.x.y. (I realize that this is a public address but the connection to it must be made from inside our network). I have set rules on the VPN to allow secure networks 147.146.0.0 and 192.168.10.0. I can reach anything on the 172.17.0.0 internal network (which is where all our servers are) but when I need to hit network 147.146.0.0(external) or 192.168.10 I must pass through the CheckPoint firewall and I can't reach anything there.

I know that traffic is attempting to pass through the VPN and not across the HomeUser's Internet tunnel as I can see the traffic counter rise on the VPN Client status window and I have tracert'd it to check.

I assume that the problem is in traversing the Firewall. Maybe there are problems NATing the HomeUser address, then assigning that DHCP (VPN client), then NATing again once it goes through the firewall (192.168.10.5). Is that too much spoofing to allow?

Thanks for any tips.
Jp

 

[Guest_imported]

I share with you some info written by a David Davis (MCSE,
CCNP, SCSA) I hope this little window will allow me to format the info so you can read it. --- wfh142077

NAT is supposed to be transparent to whatever applications it works with. Many NAT and VPN dilemmas are created by this assumption. NAT can break a VPN tunnel because NAT changes the Layer 3 network address of a packet (and checksum values), whereas the tunneling, used by an IPSec or L2TP VPN gateway, encapsulates/encrypts the Layer 3 network address of a packet with another Layer 3 network address, stripping it off on the other side.

In other words, after a packet goes through the NAT process, it has a different network address. But after a packet goes through the IPSec or L2TP VPN tunneling process, it has the same network address. This concept is invaluable when setting up and troubleshooting NAT and VPN together.

If you are using IPSec with NAT on a Cisco router, you can get around the VPN-NAT issues by selecting the traffic that is to be NATed and making sure that that traffic is not NATed but encapsulated and encrypted in the IPSec header.

In other words, you want the traffic bound for true Internet destinations to be NATed, and you want the traffic destined to travel through the IPSec tunnel to be tunneled, not NATed. On Cisco equipment, this is accomplished using an access control list.

Remember that in transport mode, the IP header is not encrypted but exposed. However, the authentication data is calculated based on the values in the IP header (among other things). When the packets arrive at the NAT router, the IP headers are modified (NATed). Upon arriving at the VPN server, the authentication data in the packet is invalid because the IP header information was modified by NAT. So the VPN server drops the packet, and the VPN client never gets connected.

Different standards and vendor implementations are being used to make this work. Most rely on some kind of IPSec encapsulation into UDP packets. Because the IPSec packet is now encapsulated, NAT devices do not affect the packet’s IP header information, and the IPSec authentication data is still valid. Thus, a connection can be made.

Check out the following URL's for more info...

http://www.cisco.com/warp/public/707/ios_D.html

http://www.cisco.com/warp/public/707/25.shtml

http://www.cisco.com/warp/public/707/ipsecnat.html

http://www.cisco.com/warp/public/707/static.html

http://www.cisco.com/warp/public/707/ios_804.html

http://www.cisco.com/warp/public/707/overload_private.shtml

 

[Jpeanut]

Thanks for that info, but it ended it being something more simple. It looks like when we were pinging the 146.147.x.y address the VPN 3000 was sending it to the internet through the firewall instead of forwarding it through the firewall to the proper network. Adding a static route on the VPN 3000 (ip route 146.147.0.0 255.255.0.0 172.17.x.y 1)fixed that problem.