topic Re: Problem with VPN traffic and Nated IPs in Firewall and Security Management

Problem with VPN traffic and Nated IPs

BrunoCiongoli — Thu, 23 Jun 2022 13:05:56 GMT

Hello colleagues

I set up a site-to-site vpn in my lab environment, this vpn worked perfectly, pinging side to side both ways. Then I tried to NAT the encryption domains of both sites and I couldn't get the traffic to tunnel.

As you can see in the image below (FW monitor) it is Natting and it takes it out through the public (eth0). But if I run a wireshark on the host pc, I see that the traffic is coming from those IPs napped but not tunneled

In the logs I see that the NAT is working fine, but then the traffic does not go through the tunnel (attached image)

I have a mgmt running 81.10 with both members of the vpn ( a cluster running 81.10 and a standalone running 80.40).

Anyone know what can it be?

Thanks

Re: Problem with VPN traffic and Nated IPs

the_rock — Thu, 23 Jun 2022 13:46:32 GMT

Hey Bruno,

What is the other side of the vpn tunnel? Based on the pictures you attached, it appears nat does take place properly in the logs.

Andy

Re: Problem with VPN traffic and Nated IPs

PhoneBoy — Thu, 23 Jun 2022 13:58:22 GMT

What precise configuration did you do for the NAT?
Did you include the NAT addresses in the encryption domain?

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Thu, 23 Jun 2022 14:04:28 GMT

Hi Andy,

Both sides are checkpoint VMs. One side is the cluster i mentioned and the other side is the Standalone, both devices are in my lab environment

Thanks, Bruno

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Thu, 23 Jun 2022 14:18:59 GMT

Hello PhoneBoy,

To better explanation, In one side, I have a cluster with a LAN (192.168.1.0/24), Inside this LAN I have a kali linux machine with the IP 192.168.1.100. In the other side I have a standalone FW with the same LAN (192.168.1.0/24) and inside this LAN a windows machine with the IP 192.168.1.100. I configure that the encryption domain for the cluster is 172.16.100.0/24 and the encryption domain for the standalone is 172.16.200.0/24 (a bit confusing, my apologies).

On the NAT table i said that if the cluster LAN want to go to the standalone LAN, go with the IP 172.16.100.X(Attached image). And if the Standalone LAN want to go to the cluster LAN, go with the IP 172.16.200.X

I hope I have explained myself as well as possible.

Thanks

Re: Problem with VPN traffic and Nated IPs

the_rock — Thu, 23 Jun 2022 14:21:03 GMT

Ok, so when you check the logs for the other side of the tunnel, do you see natted IP come in?

Andy

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Thu, 23 Jun 2022 14:29:50 GMT

No, in the other side of the tunnel i don´t see anything, because the traffic never enters the tunnel.

Re: Problem with VPN traffic and Nated IPs

the_rock — Thu, 23 Jun 2022 14:33:29 GMT

Ok, so just to make sure...tunnel does show as UP on the other side as well? If so, but you dont see traffic, then I would try do basic vpn debug and see what we get:

vpn debug trunc

vpn debug ikeon

generate traffic

then run vpn debug ikeoff

Review ike.elg and vpnd.elg* files from $FWDIR/log dir

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Fri, 24 Jun 2022 20:36:47 GMT

Hello Andy!

I´m sorry for the delay in the response. I attach a zip file with all the .elg files

thanks!

Re: Problem with VPN traffic and Nated IPs

AaronCP — Fri, 24 Jun 2022 21:32:08 GMT

Hey @BrunoCiongoli,

Are the 172.16.x.x addresses included in the VPN encryption domains?

Re: Problem with VPN traffic and Nated IPs

Vladimir — Fri, 24 Jun 2022 21:57:01 GMT

@BrunoCiongoli , are you managing both gateways from the same management server? If so and if your NAT policy is identical on both sides, shown NAT rules translate 192.168.1.0 to the same 172.16.100.0 network on both sides. If you have different NAT rules configured on each side, please show both.

While the names of the networks look good, check each network object's actual network definitions to confirm that they are inline with the names.

For encryption domains in each side, create an empty group and add to it local cluster/gateway and the 172.X.X.X.

Install the policy.

Drop existing tunnels using vpn tu command.

Try pinging again.

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Fri, 24 Jun 2022 22:46:28 GMT

Hello Aaron

Yes, both 172.16.X.X are included in the VPN encryption domains

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Fri, 24 Jun 2022 22:58:35 GMT

Hey @Vladimir

Yes, I´m managing both gateways from the same SMS. I apologize, i forgot submit the another NAT rules table, it is different (attach here)

I checked each network object and everything´s fine.

I had created the group you mentioned but without the respective cluster/gateway. I added it, installed the policies, and it still doesn't work.

According to the fwmonitor and the log (attached images) the NAT is working correctly, but the traffic does not go through the tunnel

Thanks for your time and response!

Re: Problem with VPN traffic and Nated IPs

Vladimir — Fri, 24 Jun 2022 23:33:59 GMT

Are you using mesh or star community for this setup?

I'd suggest checking that in Community | Tunnel Management | Advanced, Disabel NAT inside VPN community is not checked.

If it is, uncheck it.

...and, if it is not, changing Community | Tunnel Management | VPN Tunnel Sharing to One VPN per Gateway pair.

Re: Problem with VPN traffic and Nated IPs

Vladimir — Fri, 24 Jun 2022 23:44:24 GMT

I would also suggest installing ccc script on active cluster member and a single gateway to check VPN routing using VPN Troubleshooting | Show VPN routing option to see if 172.X.X.X is included on each side.

Re: Problem with VPN traffic and Nated IPs

CheckPointerXL — Sat, 25 Jun 2022 11:07:00 GMT

Hello, insert in your enc domain preNAT and postNAT IPs

on remote side only the postNAT ip

Re: Problem with VPN traffic and Nated IPs

BrunoCiongoli — Mon, 27 Jun 2022 15:03:12 GMT

Hello @Vladimir

I´m using a Star community.

Disabel NAT inside VPN community is not (and was not) checked.

I changed the community option to "VPN Tunnel Sharing to One VPN per Gateway pair."

I installed the ccc script on both ends (cluster and gateway). Please look the attached image for the VPN routing information.

As you can see, the 172.16.x.x is correctly listed in the encryption domain, but for some reason, all the other participating subnets are listed too. It´s like the vpn config is not recognizing the encryption domain object that I specified.

Active cluster member:

Standalone GW:

Both sides shows the same ED

On the other hand, I wonder why do I need to add the gateway´s local segments in the encryption domain. Probably I was not clear enought with my first post, but what i´m trying to test is to hide overlaping networks on VPN. For that I´m using the same LAN (192.168.1.0/24) IPs on both sides, so I´m not sure of what would be the behavior if the same IP address segment is set in both EDs.

Thanks in advance for your time and help

Re: Problem with VPN traffic and Nated IPs

Vladimir — Mon, 27 Jun 2022 15:19:23 GMT

Adding gateways to the groups representing encryption domains was done to make use of per-gateway pair tunnel.

You can try removing them from the groups, changing tunnel properties in community back to one per subnet pair and testing it again, checking with ccc how your EDs look like in desired configuration.

Re: Problem with VPN traffic and Nated IPs

Vladimir — Mon, 27 Jun 2022 15:35:32 GMT

P.S. It does not look like sk116097 "Destination NAT traffic not encrypted when the original destination included in the NATting gateway encryption domain", so it should work in theory.

I would also suggest changing the community topology to mesh, if it does not break the intended configuration, and give it another shot.

Re: Problem with VPN traffic and Nated IPs

Vladimir — Mon, 27 Jun 2022 16:05:21 GMT

And you can use "Set VPN domain for VPN communities" feature:

To see if it'll limit EDs to 172.16.X.0/24 networks, thus avoiding collision EDs preventing NAT for VPN.