Traffic through the VPN trusted interface is sent encrypted instead of clear

[anhht4]

Dear all,

Hope you are all doing well! 

Just a quick query, if anyone has this configuration anymore?  Is it working properly?

sk56384 - How To Create a Redundant, Service-based MPLS/Encrypted Link VPN

We are kind of hopeless after moving from open server R81.10 to 9400 R81.20...The S2S traffic is being encrypted on trusted interface and sometime, it's working on Internet link only, eventhough the MPLS link is still available. It can't be fixed by reset tunnel, only after a full cluster rebooted.

We've opened TAC case but kind of stuck... SR#6-0004443268 

Appreciate if any hints/help!

BR,

Andy

[Chris_Atkinson]

Has been quite some time since I last used this configuration myself.

Temporarily switching SecureXL to KPPAK might be helpful for diagnostic purposes if you are really stuck with TAC.

[anhht4]

Sorry for the delayed response and many thanks for your advice.

It's already running with KPPAK due to non optimal ruleset... 😞 

We already tried to switch off secureXL as well but it did not help, even changing from usermode to kernel mode also not working, I was told that it's not support on 9400 with R81.20 anymore. 

On the old openserver R81.10, it was running with kernel mode. 

Any other ideas? May I know which version & take was working for you? 

[the_rock]

I did this with customer this summer and worked fine.

Happy to do remote if you allow it and we can check together.

[anhht4]

Hey Andy, 

Sorry for the delayed response and many thanks for your kind offer. I really appreciate it.

Unfortunately, I am not allowed to do so...

May I know which Gaia OS version and take was working for you?

It's really strange behaviour that we can only see clear text on oneway from R81.10 to R81.20 but not the another way around.

In tcpdump on MPLS interface, we can only see echo reply, when do ping from R81.20 --> R81.10:

tcpdump -nnei bond11.14 host 172.31.55.165 and host 10.64.8.117 -s 0

And between R81.20 GWs, there even is no traffic can be seen on MPLS interfaces, except ESP traffic:

We tried several approaches like disable SecureXL, exclude GW's external IP addresses from VPN domain, exclude VPN encryption for MPLS links/IP ranges by modifying crypt.def from SMS, enable manual source IP address of chosen interface from link selection...But still no luck.

Do you perhaps have any other idea? 

Many thanks again!

BR,

Andy

[the_rock]

Yes, both R81.20 and R82 as well, latest jumbos.

[the_rock]

Just curious, how is tunnel management configured?

 

[anhht4]

The GW is participating 2 communities (star and mesh) but we have tunnel management set like this:

Regarding the RIM, it looks like that it is not fit to our design, as I understand, with RIM - the Routers stays behind Firewall and reroute the traffic once VPN tunnel down, which is completely opposite with what we are trying to achieve by following sk56384. The primary line should be MPLS (routers stay infront of Firewalls and propagate BGP routes to peers), all traffic should be routed to MPLS line as long as the peers having MPLS (some locations has only internet line)

We verified that all the routes are propagated, the traffic is only on MPLS but it's encrypted, which prevent us to do QoS on MPLS routers.

BTW, is it recommend to set Permanent tunnel if we have only Checkpoint GW? Will it be any performance impact if we have 60+ GWs in a community? I am somehow not so clear with this setting, as I tried to set it once then the tunnels became unstable. 

Many thanks in advance!

Best regards,

Andy

[the_rock]

Thanks for the detailed explanation @anhht4 . I can tell you from all my experience with building route based tunnels, and I must have done at least 100 of them, that setting for permanent tunnel should not relate to number of gateways in community at all. Now, I always found its best to enable it, along with per gateway setting IF it is indeed route based with BGP involved. Now, if its domain based, then you can still use it, but it would not be as relevant.

[the_rock]

See if this post I made last year helps.

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-tunnel-to-Azure/m-p/206179/emc...

[anhht4]

Many thanks Andy for sharing, I am considering this for our WAN redesign. 

Anyway, TAC is involved and case already escated to R&D, will keep posted.

Cheers,

Andy

[the_rock]

Yes, of course!

[the_rock]

If you can, I would definitely try tunnel management as per gateway and permanent tunnel option and see if it makes any difference.

[the_rock]

Hey Andy,

Any luck with this?

[anhht4]

Hey Andy,

Apologies for delayed response. I will try this tonight and get back to you with result. 

Recently, the tunnel was frozen, no traffic passing through over the tunnel event all tunnels were up. After a tunnel reset, it's back to normal. I wonder if we should apply this : sk180956 - Traffic through a VPN tunnel does not flow as expected when "Link Selection probing" and ... for the R81.10 GW. We do have NAT-T enabled on both peers. 

Any advice on this as well?

Many thanks!

BR,

Andy

[the_rock]

If the sk applies to your setup, then yes.