IPSec Tunnel UP but encryption domains unable to communicate(UDP encapsulation NATT)

[Ihenock1011]

Hi All

We have a checkpoint GW r81.10, where we have created multiple S2S IPSec VPN with other clients, but specifically, with 1 client(StronSwan) , we are having communication problems the tunnel shows UP however the endpoints are unable to communicate one thing I observed different from the other 3rd parties tunnels is under the SmartView the tunnel detail shows monitor UDP encapsulation NATT.

I'm unsure if this is causing the issue. Could you please help?

Thanks,

[the_rock]

Hey bro,

So, lets start with whats logical here...so, if tunnel is UP, that 100% means phase 1 and 2 settings are good, no issues there. Now, if traffic is not working, its possible that something with vpn enc. domains might not be matching.

Some questions:

-is it domain or route based?

-sta or meshed community?

-if star, how is routing configured within the community?

-any NAT used?

Andy

[Ihenock1011]

Hey Andy

-is it domain or route based?

It is Route based

-sta or meshed community?

Meshed Community

-any NAT used?

The pure IP goes through the tunnel there is no NAT from my end.

[the_rock]

K, so if its meshed, then no option to set any routing, which is fine, since every "entity" talks to one another, if you will. So, do you have super basic diagram of maybe example of an IP thats fialing? Just scramble something on a piece of paper and take a picture and upload it, not an issue, just blur out any sensitive data.

Did you try ip r g command with an IP address in question to make sure it uses correct route? example ip r g 8.8.8.8

What about simple zdebug and also basic vpn debug?

vpn debug trunc

vpn debug ikeon

-generate some traffic for 1 minute (ping)

vpn debug ikeoff

fw ctl debug 0 (to turn off debugs)

Look for vpnd* and ike* files in $FWDIR/log dir

Best,

Andy

[Ihenock1011]

Andy, does this debug commands create some issue because it is a production environment if the debug command needs maintenance window kindly please let me know.

[the_rock]

I had done it probably more than 100 times, never had an issue. Those are super light and I know people sometimes leave them on for 2 weeks and its fine. If you want to be super careful and do it after hours, thats your choice, but personally, I never had any issues, even in production.

Andy

[the_rock]

@Ihenock1011 Were you able to run the debug mate?

Andy

[Ihenock1011]

After discussing with the partner, they informed me that their endpoint machine is behind a NAT device. When traffic reaches the peer IP, which is also their machine's public IP, it will be translated and forwarded to their internal host. As I understand it, IPSec might not function correctly in this scenario. Both machines behind the peer IP should ideally be configured as they are while traversing the tunnel. Is there a workaround for this situation?

[the_rock]

Did you make sure NAT is NOT disabled inside vpn community? Also, do you have simple diagram that would illustrate this scenario?

Andy

[Ihenock1011]

Inside VPN community I checked on the advanced tab disable NAT b/n communities. I will attach the free sketch of network topology removing sensitive information

[the_rock]

That could be the issue then, because you need nat, so that option should not be ticked.

Andy

[Ihenock1011]

Okay then let me check that way and I will Update you.

[the_rock]

Sounds good, let us know how it goes.

Andy

[Ihenock1011]

I tried the enable and disable NAT it doesnt give me a solution.

after the debug I get the two outputs from the vpnd.elg file

TSPayload::constructRelevantTS: checking relevancy of range: "Partners Peer IP x.x.x.x"
TSPayload::isRelevantTS_ipv4 : range  is outside of TS range "Partners Peer IP x.x.x.x". TS range is not relevant.

[the_rock]

Sounds like vpn domain issue...

[Ihenock1011]

what does it mean Andy?

[the_rock]

It would appear something with phase 2 is not matching. Based on that message, most likely vpn enc domains.

[Zolocofxp]

There is a lot of fabric to be cut here... Like master @the_rock mentioned, it is most likely a phase 2 issue.
- Is phase 2 tunnel actually being created? as expert, run the command vpn tu tlist -p [peer_ip]. There should be one or more tunnels depending on your community and domain config. For traffic to be encrypted an Out SPI must exist.
- If there are no tunnels active, there is definitely an issue with encryption domains.
- NATT can work with specific Traffic Selectors(TS). For interoperability sake, I would set VPN Tunnel Sharing as "One Tunnel per Gateway pair" and apply rules accordingly. This will create a tunnel with 0.0.0.0/0 in both TS, like the following example:

Again, you have to do some debugging to determine exactly what is going on. It can be from a bad proposal to a routing issue. 

[the_rock]

Thank you @Zolocofxp for that, but im FAR from being a master lol

But yes, I agree with your assesment, definitely phase 2 issue.

Andy