Need help in understanding NAT in relation to mobile VPN traffic

[Joe_Kanaszka]

HI all.

I changed the mask on the "CP_default_Office_Mode_addresses_pool" network group from /25 to /26. to make room for 4 nets.

My "CP default Office Mode address pool" range changed from 10.10.10.1-126 to 10.10.10.65 - 126.

(The plan was to reserve one of the nets for use in the ipassignement.conf file.  We need a handful of users to always get the same static ip address when WFH.)

I created a new network object that contained IPs in the range of 10.10.10.1-62.  I created my ipassignment.conf file and assigned 10 users with static ips from this new IP range.

I made sure to add this new group to my remote access encryption domain

We tested the new static IPs while signed into the mobile VPN and all seemed fine.  However, we were not able to access our CIFS file share server.  We couldn't ping it...

I was able to access other resources on my remote network.

I checked DNS - no issues.  No double entries.

When I ran fw monitor while pinging the CIFS server I was not receiving any ICMP replies back...

After checking the new network object I created I noticed that I did not have "Add automatic address translation rules" "Hide behind the gateway" checked.  

After checking the option to use "hide NAT"  and re-logging into the mobile access VPN, I was able to access my CIFS server.

Now for my question:

Why would I be able to ping other machines on the same network but not access this one IP until I enabled Hide NAT?

[the_rock]

Valid question, for sure. I know by default, OM net is set to hide behind gw for nat, thats been like that probaly since the begging of Check Point. Now, just to make sure, are you saying, say IP 10.10.10.100 was fine to access WITHOUT nat, but then say 10.10.10.99 was NOT?

Andy

[Joe_Kanaszka]

Exactly!  I was able to ping 10.10.10.100 but not .99 

[the_rock]

Got it. Ok, so not sure if you can replicate the issue, but if you could, I would run below and compare.

Andy

-traceroute (see where it fails)

-from the fw, ip r g ip_address -> example : ip r g 10.10.10.99

-tcpdump on the fw for affected ip, ie tcpdump -enni any host 10.10.10.99

-maybe quick zdebug to see if anything gets dropped -> fw ctl zdebug + drop | grep 10.10.10.99

-any logs filtering for that IP

Thats all I can think off for now bro. Other than that, Im afriad not much we can offer unless problem is there, so it can be troubleshot.

Andy

[Joe_Kanaszka]

On a side note:

What is the # ip r g "ip address" command?  Never seen that although I see what it does.

[the_rock]

Just shows you the path fw uses to get to whatever IP bro.

example in my lab.

Andy

[Expert@CP-GW:0]# ip r g 8.8.8.8
8.8.8.8 via 172.16.10.1 dev eth0 src 172.16.10.249
cache
[Expert@CP-GW:0]#

[Expert@CP-GW:0]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.10.1 0.0.0.0 UG 0 0 0 eth0
172.16.10.0 * 255.255.255.0 U 0 0 0 eth0
172.31.10.0 * 255.255.255.0 U 0 0 0 eth1
192.168.10.0 * 255.255.254.0 U 0 0 0 eth2
[Expert@CP-GW:0]#

[Joe_Kanaszka]

Cool.  Thank u.

[the_rock]

Np, message me any time if you want to do remote session.

[Joe_Kanaszka]

Thank you so much Rock!

[Lesley]

Could be a lot of reasons. Think about routing on network, servers etc.

Or even ACL that has been set on the CIFS server. The server does probably not know where to route the real ip or blocks it. 

Maybe it routes it wrong end it ends on the wrong interface of the firewall (then you get anti-spoofing messages or out of state)

Based on the info you shared it is very unlikely that it was a firewall problem and therefore I cannot help further. 

[Joe_Kanaszka]

Based on the info you shared it is very unlikely that it was a firewall problem and therefore I cannot help further. 

Thank you.  Well - it sure does seem like a FW problem being that right after I enabled "Hide NAT" I was able to ping the server....

[the_rock]

Dont worry brother, no matter the issue, we can ALWAYS help, or at least guide you in the right direction.

Andy

[Lesley]

With NAT you change the outgoing IP. Not the firewall fault the that the CIFS server is not sending a ping reply to the real ip.

Is free advise here if you don't want to follow fine by me. 

[fabionfsc]

With an automatic Hide NAT, the Firewall basically delivers the communication using the Firewall's own IP. We need to analyze who the Default Gateway of your CIFS server is, because it seems that it is not the Firewall that you are connected to via Remote Access VPN, therefore, it does not know the Office Mode network of your Firewall.

Log in to your CIFS server and check if it can ping the real IP that was assigned to you in Office Mode. The communication worked, because the Default Gateway of your CIFS server was able to communicate with the Firewall that you are connected to via Remote Access, but for some reason it cannot communicate with your real Office Mode IP.

In other words, since the Check Point Firewall stores the communications in the NAT table, when the packet is returned to the Firewall's IP, it knows your Office Mode and delivers the packet to you (with Automatic Hide NAT enabled), but the IP that arrives at the CIFS server is the Firewall's IP.

If the CIFS server is behind another Firewall, make a route on this Firewall, something like {If Destination = Office Mode, then Default Gateway = Your Office Mode Firewall IP}.

[Joe_Kanaszka]

This makes sense.  Thank you so much fabionfsc!

[the_rock]

Fantastic explanation @fabionfsc 

[emmap]

One thing, your office mode range shouldn't be in your VPN encryption domain. The encryption domain is to contain the on-prem subnets and networks that you want to allow VPN users to get to, not the VPN users themselves. I'm not suggesting that this is the cause of the problem, just a note on your comment there. It should however it something that the internal network devices will route back to the gateway if you don't have the NAT enabled on it.

[Joe_Kanaszka]

Thank you emmap