Original IP address does not come through in a VPN tunnel

[terri8369]

We have Version 80.10 with all patches. We have ~100 small devices in remote locations, a blend of utm-1, cp1100, and 1430 devices. I just found that when a user at a remote location goes to something else on our network, I am getting the ip address of our primary firewall instead of the employees ip address. Is this normal? It is interfering with the way our proxy server works. It has been occurring for some time now, and getting progressively worse, most likely because I do not think the old devices are having the issue and as we replace them the newer devices do and are making the situation worsen. So our set up would be...

employee >> CP1100 >> tunnel >> primary gateway >> something on our network
1.1.2.5 1.1.2.1 172.1.1.2 172.1.1.2

A debug shows the right address coming back to the gateway. Is this normal? I am trying to figure out how I could follow the traffic is an employee became disgruntled and did something to a site.... all I would know is they are from one of 100 remote locations if I can't get their original IP.

The something on our network I am looking at right now is our proxy server which shows multiple users with the gateway address, and IIS logs with c-ip and x-forwarded-for on, with the primary gateway coming through as c-ip and nothing as x-forward-for.

Any thoughts are appreciated.

terri

[ShadowPeak.com]

We have Version 80.10 with all patches. We have ~100 small devices in remote locations, a blend of utm-1, cp1100, and 1430 devices. I just found that when a user at a remote location goes to something else on our network, I am getting the ip address of our primary firewall instead of the employees ip address. Is this normal? It is interfering with the way our proxy server works. It has been occurring for some time now, and getting progressively worse, most likely because I do not think the old devices are having the issue and as we replace them the newer devices do and are making the situation worsen. So our set up would be...

employee >> CP1100 >> tunnel >> primary gateway >> something on our network
1.1.2.5 1.1.2.1 172.1.1.2 172.1.1.2

A debug shows the right address coming back to the gateway. Is this normal? I am trying to figure out how I could follow the traffic is an employee became disgruntled and did something to a site.... all I would know is they are from one of 100 remote locations if I can't get their original IP.

The something on our network I am looking at right now is our proxy server which shows multiple users with the gateway address, and IIS logs with c-ip and x-forwarded-for on, with the primary gateway coming through as c-ip and nothing as x-forward-for.

Any thoughts are appreciated.

terri

Did you check the "Disable NAT in VPN Community" checkbox on the VPN Community properties?

[terri8369]

Did you check the "Disable NAT in VPN Community" checkbox on the VPN Community properties?

Thank you for responding, yes, we have that checked for both center and satellite gateways.

[northlandboy]

Sounds like the NAT is happening on the primary gateway, *after* the packet has come out of the VPN tunnel from the remote site?

So might be worth going through all your NAT rules the primary gateway, and check for things like auto-hide NAT config for all internal networks.

[terri8369]

Sounds like the NAT is happening on the primary gateway, *after* the packet has come out of the VPN tunnel from the remote site?

So might be worth going through all your NAT rules the primary gateway, and check for things like auto-hide NAT config for all internal networks.

THANK YOU SO MUCH!!! That was it, I reviewed all the NAT rules and there was one in there with all the vlans in it with an obscure kind of name that was making sure they kept their original IP. I cannot thank you enough, you are wonderful. Have a great weekend!

[northlandboy]

Great to hear that you found it.

I've had similar experiences in the past, especially with deeply nested groups that someone slips an overly large subnet into...takes a little while to figure out what's going on

[terri8369]

Now that I have this working, I would like to ask an additional question so that I understand why the nat is needed, if indeed it is, and to make sure I should not be looking for a configuration problem in my setup.

I would have expected that in a tunnel, the original IP address would remain the same. It would go through the tunnel and the center gateway and then to other things on our network, and the client IP would remain the same. Ours is changing to the center gateway address. The NAT rule is making sure the IP address stays the same. Is this expected behavior?

So here is what I have...

client 1.1.2.1 >> CP1100 >> Tunnel >> Center Gateway 172.1.1.1 >> Webserver on network log shows 172.1.1.1


What I would have expected is...

client 1.1.2.1 >> CP1100 >> Tunnel >> Center Gateway 172.1.1.1 >> Webserver on network log shows 1.1.2.1


So the NAT rule makes the second scenario happen, but I'm wondering if I have something configured wrong to make the NAT rule required, or is that just how it works? If what I expected is what should be happening, I have some clean up to do. We are running r80.10, but made a conversion from r77.30 where we were using SmartProvisioning. Maybe SP was doing more behind the scenes than I knew.

Any help is appreciated. I have been googling how a VPN tunnel works, but have not yet found a diagram or anything that explains this piece.

[ShadowPeak.com]

Now that I have this working, I would like to ask an additional question so that I understand why the nat is needed, if indeed it is, and to make sure I should not be looking for a configuration problem in my setup.

I would have expected that in a tunnel, the original IP address would remain the same. It would go through the tunnel and the center gateway and then to other things on our network, and the client IP would remain the same. Ours is changing to the center gateway address. The NAT rule is making sure the IP address stays the same. Is this expected behavior?

So here is what I have...

client 1.1.2.1 >> CP1100 >> Tunnel >> Center Gateway 172.1.1.1 >> Webserver on network log shows 172.1.1.1


What I would have expected is...

client 1.1.2.1 >> CP1100 >> Tunnel >> Center Gateway 172.1.1.1 >> Webserver on network log shows 1.1.2.1


So the NAT rule makes the second scenario happen, but I'm wondering if I have something configured wrong to make the NAT rule required, or is that just how it works? If what I expected is what should be happening, I have some clean up to do. We are running r80.10, but made a conversion from r77.30 where we were using SmartProvisioning. Maybe SP was doing more behind the scenes than I knew.

Any help is appreciated. I have been googling how a VPN tunnel works, but have not yet found a diagram or anything that explains this piece.

If using the Automatic NAT setup technique (i.e. defining it on the NAT tab of a Host/Network object), the automatic rule(s) created will attempt to NAT traffic to/from that host/network regardless of where it came from or is going, and even traffic involved with a VPN tunnel. This is diametrically opposed to how NAT is configured on other vendors such as Cisco/Juniper/Palo Alto who use an explicit zone pair or interface pair to precisely define when NAT should occur. With those other vendors if there is no matching interface/zone pair no NAT occurs. However on Check Point the chances of that same traffic getting caught in an Automatically created NAT rule is very high. So at the top of the Check Point NAT rule base it is very common to specify manual "no-NAT" or "anti-NAT" rules to specify where you do *not* want NAT to occur (traffic between internal networks and DMZs is a good example), and for all other situations just let the traffic fall down to the Automatic NAT rule. There is currently no easy way to replicate the "zone pair" NAT approach on a Check Point since Security Zones cannot be used in NAT rules at all, which makes converting NAT policies from the zone/interface pair vendors to Check Point rather cumbersome.

Specifically in the case of IPSec VPNs, traffic entering or leaving a VPN tunnel is subject to the NAT policy just like any other traffic. However in general you don't want to NAT traffic coming in or out of a VPN tunnel unless there is an addressing conflict between the two sides, and in some other generally not-so-happy situations. When setting up a new VPN Community if you are SURE that you will never need traffic NATted in or out of those tunnels, it it *highly* recommended to set the checkbox "disable NAT inside the VPN Community" in the Community properties. This setting causes all tunneled traffic involved with that Community's VPN to completely ignore the NAT policy. This checkbox is critical to ensure that future unrelated NAT changes do not accidentally start catching existing VPN tunnel traffic in new NAT rules, which will completely break connectivity through that original VPN tunnel, and probably all of your other existing ones as well thus causing a massive VPN outage. Been there, done that. Not fun.

[terri8369]

Thank you for taking the time out to explain this to me. To be honest you are eons ahead of me in this, so it will take me time to read and totally understand what you are saying, but I appreciate it more than you could know!

Thanks again!