Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Matlu
Advisor
Jump to solution

Disable NAT-T in Checkpoint GW.

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.

0 Kudos
1 Solution

Accepted Solutions
Matlu
Advisor

We found the error, and fixed it.

It's weird, but we'd better not even touch it, hahaha.

It turns out, we touched the configuration of the

"VPN TUNNEL SHARING"

Select the option: "One VPN Tunnel per each pair of hosts" .... Once this option was selected, it started to work.

VPN1.png

Checkpoint really surprises me 🤣😲

We were seeing the traffic coming out of the encrypted firewall, and everything was fine for us, but the Cisco ASA was not seeing the traffic coming to their equipment, and we had to move to that option, once we did that, it started to work normally.

I really don't understand why, but at least it is working. 🙃

View solution in original post

(1)
42 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
Matlu
Advisor

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.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Matlu
Advisor

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?

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
PhoneBoy
Admin
Admin

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

image.png

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
Legend
Legend

Thanks for that, totally forgot about that setting 🙂

0 Kudos
Zolocofxp
Collaborator

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

nat.png

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

Matlu
Advisor

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

0 Kudos
Zolocofxp
Collaborator

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. 

0 Kudos
Matlu
Advisor

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.

VPN2.png

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).

VPN1.png

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.

0 Kudos
Zolocofxp
Collaborator

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. 😁

0 Kudos
the_rock
Legend
Legend

I agree with that approach 🙂

Andy

0 Kudos
Matlu
Advisor

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

0 Kudos
the_rock
Legend
Legend

🤣🤣🤣🤣

0 Kudos
Matlu
Advisor

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?

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Zolocofxp
Collaborator

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?

0 Kudos
Matlu
Advisor

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)



0 Kudos
the_rock
Legend
Legend

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

🌍

0 Kudos
Matlu
Advisor

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)."

(1)
the_rock
Legend
Legend

@Matlu 

Eres el mejor 😉

✔✌

0 Kudos
Zolocofxp
Collaborator

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
Legend
Legend

@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

0 Kudos
Matlu
Advisor

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).

0 Kudos
Zolocofxp
Collaborator

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
Advisor

Buddy,

What is the file to review?

IKE.png

Because I get several.

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

It is worth mentioning that our VPN is in IKEv2.

0 Kudos
Zolocofxp
Collaborator

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

0 Kudos
Matlu
Advisor

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events