GWs decided on NAT-T while they have no nat device in the middle

[Amir_Arama]

hi

we have two GWs which having site to site vpn.

they located in different geographic location, but they have Layer 2 line, so they basically see each other by arp.

so let's say 192.168.1.2/29 and 192.168.1.6/29 (and by these addresses they know each other as peers)

for some reason, instead of using ESP over proto:50, they are deciding to use NAT-T

i can't figure out why. and i was hoping to fix it, to save the double encapsulation. is there a way to understand what is behind this decision?

thanks

gws are single gws with r80.40 latest take. managed by the same mgmt, share the same vpn community.

[the_rock]

Are you saying this worked fine before and it just happened with no change? It makes no sense for nat-t, if there is nothing in the middle...you may see that for vpn clients connection, but thats different.

[Amir_Arama · Accepted solution]

ok

i found some sk165003

so i just tried to change the interface that facing the other gw to be configured as EXTERNAL, and it solved it. can't say i understand why it matters for now. and if it's must for the esp.

good night

[the_rock]

k, good to know!

[Swordfish]

A few month ago we had the same issue (R80.40) without changing anything. We had a site2site VPN running for a long time without NAT-T. Suddenly, whenever our Check Point wants to initiate the tunnel, it used NAT-T and the remote site (Cisco ASA) rejected this attempt, because there was no NAT-T device in place.

One of our gateways crashed a few hours before the issue occurred for the first time, due to a memory error in the kernel. So we had TAC and R&D involved but nobody could find the cause for this NAT-T issue. The memory error got patched but still, our Check Point Gateways always tried to use NAT-T. So we ended up rebooting BOTH nodes at the same time, so no connection etc. could be synced back.

Turns out, this solved our issue. So the crash caused by the memory error, seemed to cause this NAT-T issue.