Disable NAT-T in Checkpoint GW.

[Matlu]

Hello,

Is NAT-T enabled by default on Checkpoint equipment?

We have a GW, where we have created multiple VPNs with other clients, but specifically, with 1 client (Cisco ASA), we are having communication problems and according to the tests that the endpoint performs, suggests us to "disable" the NAT-T, but this option of disabling the NAT-T in the GW, affects in general to all the VPNs that you have created, right?

Could someone please confirm this for me.

Greetings.

[PhoneBoy]

Yes, it affects all VPNs that terminate on that gateway.

[Matlu]

Hello.

Is it advisable to disable NAT-T on a Checkpoint GW?

We have a S2S VPN against a Cisco ASA, but when we work the VPN using a NAT from our side, the other side, fails to see traffic on their equipment.

Example:

Our Real segment: 10.10.100.0/24
Remote segment: 10.11.1.50/32
NAT IP from our side: 172.10.15.100/32

When we use this flow, the remote peer does not see any traffic coming to its side (the tunnel on F1 and F2 are above).

Cisco ASA, indicates that they have bad experiences with Checkpoint when NAT is used to "hide" the real IPs/Segments, and they relate it to the use of NAT-T that is enabled by default in Checkpoint.

Greetings.

[the_rock]

What option are you referring to bro? You can disable/enable nat per vpn community, its in advanced tab under specific vpn community object.

Andy

[Matlu]

I mean disabling NAT-T for a VPN.

Since the remote peer assumes that it is the Checkpoint's NAT-T, which is generating communication problems in phase 2 of the VPN.

According to the documentation and PhoneBoy's comment, disabling NAT-T is a global setting that "affects" the entire GW.

But is it advisable to disable this global setting for the GW?

[the_rock]

I never seen any global settings for nat-t myself. Only one I know for vpn is one I mentioned.

Andy

[PhoneBoy]

There is a gateway-specific setting for NAT-T here:

However, it applies to all VPNs.
I've never heard of NAT-T itself causing issues with Cisco (though the differences in subnetting can cause issues).

[the_rock]

Thanks for that, totally forgot about that setting 🙂

[Zolocofxp]

You can disable NAT-T for that specific peer using Check Point Database Tool. Especifically, you need to disable it when initiating traffic.

I suggest you run a VPN Debug, I believe you are having a P2 negotiating issue that could be easily solved.

[Matlu]

The VPN is up and running on both phases, but they do not see the traffic coming to theWe see traffic coming out of the Firewall, and encrypted.

We have used TCPDUMP, FW MONITOR, and checked the logs, over and over again, the traffic is confirmed to be encrypted coming out of our Checkpoint, but they don't see it "coming in".

If we work with the real Local IPs, on both sides, they do see the traffic coming in.

They blame it on the NAT-T of Checkpoint.

According to the theory, Checkpoint is not the initiator in the NAT-T negotiation, as far as I remember, Checkpoint is normally in "listening" mode for this type of service

[Zolocofxp]

Have both ends send traffic to bring up both phases. In CLI, expert mode, have a look at established tunnel(s) for that peer. There should be only 1 s2s tunnel active with an Out SPI created, Traffic Selector should be /32 for you and your peer. If you see different results, share your findings. We might be able to help. 

[Matlu]

On our side, we have 3 segments:

10.10.120.0/24
10.10.122.0/24
10.10.249.0/24

We use a NAT for these 3 segments:

IP NAT: 10.11.83.145

The IPs on the CISCO ASA side are:

10.11.6.190
10.11.6.191
10.11.1.192

We are doing a Hide NAT.

We have configured the tunnel characteristics in this way.

Right now, the VPN is "down", since we are not testing right now (I understand that it is down, since the message is NO OUTBOUND SA).

I share the result of a test we did, when the tunnel is up.
There you can see that the traffic is encrypted, but the other side can not see the traffic on your computer.

[Zolocofxp]

I'd still recommend running a Debug to check your proposals. There should be only one tunnel from your NAT IP 10.11.83.145/32 to each of peers subnet  10.11.6.x/x and 10.11.1.x/x 

Sorry for my awful writing skills btw... I'm a spanish native speaker. 😁

[the_rock]

I agree with that approach 🙂

Andy

[Matlu]

Entonces, mucho mas sencillo, transmitir la idea de mi problema, amigo 🤣

[the_rock]

🤣🤣🤣🤣

[Matlu]

In my scenario, what is the appropriate option in the configuration of the

"VPN TUNNEL SHARING" CONFIGURATION?

Currently, based on my diagram, it is set to "One VPN tunnel per subnet pair".

This is based on the fact that on our side, we have 3 segments, and on the Cisco ASA side, we have 3 Hosts.

Is this option the most viable?

[the_rock]

Ok...in my personal opinion and I been wrong MANY times (lol) and Im sure this would not be the last time (haha), BUT...from all my experience and people asking about that setting, I found that IF you have combination of subnets and hosts (does not matter on what side of the tunnel), you are best to use "per gateway" option.

I even had customers change that on the phone with TAC before and fixed the issue.

Anyway, just a suggestion.

Andy

[Zolocofxp]

Maestro,

Realiza un debugging... Con el IKEView podrás evaluar las negociaciones. Ya me he topado con caso similar con equipo ASA. Ellos son muy quisquillosos a la hora de negociar propuestas. Lo damos por hecho, pero ¿Seguro la IP NAT está en tu dominio de encriptación local?

El peer ¿Cómo tiene configurado los Traffic Selector (dominio de encriptación) local y remoto?

[Matlu]

Hola, Dr.

Es habilitar los comandos:

vpn debug trunc
vpn debug ikeon

Y generar trafico de mi lado, hacia el CISCO ASA, y extraer el archivo ike.elg, para abrirlo en el IKEView, es correcto?

Cisco ASA, nos pidió que usemos un segmento NAT, el cual es 10.11.83.144/29.

Este segmento NAT y las Redes Locales Reales de nuestro lado, ya están en nuestra VPN DOMAIN.

No se que tan "importante" sea el detalle, de que el SNAT que estamos haciendo, es usando 1 sola IP del segmento que ASA nos dio (La NAT es unicamente usando la IP 10.11.83.145)

[the_rock]

Hermano

Para mantenerlo consistente, tal vez sea mejor usar el inglés. Entiendo el español bastante bien, pero para ayudar a otros que puedan revisar esta publicación en el futuro, eso es todo 😉

Bien

Andy

🌍

[Matlu]

I restate, the comment, to be of help in the future:

"Buddy,

It is to enable the commands:

vpn debug trunc
vpn debug ikeon

And generate traffic from my side, to the CISCO ASA, and extract the ike.elg file, to open it in the IKEView, is it correct?

Cisco ASA, asked us to use a NAT segment, which is 10.11.83.144/29.

This NAT segment and the Real Local Networks on our side, are already in our VPN DOMAIN.

I don't know how "important" is the detail, that the SNAT we are doing, is using only 1 IP of the segment that ASA gave us (The NAT is only using the IP 10.11.83.145)."

[the_rock]

@Matlu 

Eres el mejor 😉

✔✌

[Zolocofxp]

I guess keeping it in English is for the best.

The process you described is correct. Once you open the .elg file, you should see what your proposals are.  You are one step closer to solving the issue. 

[the_rock]

@Matlu 

What @Zolocofxp is true, but, maybe download ikeview tool and use that. I mean, you can open the file in notepad++ as well, but might look bit goofy lol

Andy

[Matlu]

I will apply the recommendation.

Now, the VPN is down (as far as I know, it is normal to see it down, when there is no interesting traffic going through the tunnel).

I guess, it is just a matter of activating the debug, and test traffic between both ends, without the need to "restart" the VPN tunnel, right?

I don't think it's a problem that my SNAT rule only declares to an IP in the 10.11.83.144/28 segment, right?

Because my NAT rule only puts in the "Translated Source" column the IP 10.11.83.145 (using Hide NAT mode).

[Zolocofxp]

Yeah, that snat is irrelevant as long as a phase 2 is established between the interesting subnets (10.11.83.144/29<>10.11.6.x/x for example). Keep in mind that a rule must be created where traffic is allowed for your NATed subnets. 

[Matlu]

Buddy,

What is the file to review?

Because I get several.

Is it "ike.elg"? Or is it the iked.elg?

It is worth mentioning that our VPN is in IKEv2.

[Zolocofxp]

For IKEv2, you have to open legacy_ikev2.xmll at least for R81.10/20

[Matlu]

And just for knowledge, for IKEv1, if the ike.elg file is used to read it in the IKEView?

I'm going to test the VPN by changing it from v2 to v1.