topic Re: Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs in Firewall and Security Management

Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs

IanS94 — Sun, 05 Jul 2020 10:52:50 GMT

Hi all,

We have multiple spoke networks connected over IPSec VPN (numbered VTI, Route based VPN), with BGP.

These have been configured with an empty encryption domain and work seamlessly for all traffic types with wire mode or without.. except for IPSec over the top of our VPN tunnels which doesn’t work in either wire or firewall configuration. With wire mode off, the logs show it’s hitting our allow rule, but the log is saying “Drop” and “Failed to enforce VPN policy (11)”

A customer has a hard requirement to form IPSec encryption from their host, from within their network, to a host in another network we also VPN with. MTUs are set correctly and this worked previously inside tunnels from Palo Alto firewalls natively, without any issues or extra configuration

It seems likely the empty encryption domain is causing some fuss

Is there guidance available around why IPSec within our VPN is any different to say, TLS within our VPN, and more importantly, is it possible to allow this type of traffic to flow over our firewalls, without losing key requirements we have (BGP route based vpn)

Kind Regards,

Ian

Re: Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs

PhoneBoy — Mon, 06 Jul 2020 01:59:47 GMT

I don't think it's the empty encryption domain per-se that's causing the issue, it's that IPsec is treated differently by the gateway than other traffic.
What precise versions of code are involved here?

Re: Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs

IanS94 — Mon, 06 Jul 2020 13:39:20 GMT

Hi PhoneBoy,

I'm aware of your legendary status around these parts, so thanks for your input.. (hoping flattery helps)

Our Security Gateway has the following versions:

Gateway Release: CheckPoint GAIA R80.30
Kernel: 3.10.0-693cpx86_64
Build Number: 273

The manager has the following versions:

Gateway Release: CheckPoint GAIA R80.30
Kernel: 3.10.0-957.5.1cpx86_64
Build Number: 200
I can see that there's a take 196 update available, although the take 191 we're on isn't that old and can upgrade if appropriate

Both of these are deployed from the AWS R80.30 AMIs and are around 2 months old.

It does seem something along the lines of the gateway trying to manage the IPSec going through it in some way.. initial thoughts being it assumed it should respond to the IKE itself and simply didn't know how (psk/enc type etc]? With every Windows device on any Windows domain trying to run IKE to every other Windows machine, there's a lot of IKE passing through here being blocked which can't be good for performance tbh, and we don't really mind it being outside of our log visibility (we know the source/destination ranges and whether they'd be trusted). The main one is the source/dest in question, which the IPSec over us 'as a cable' is pretty important.

If these aren't the versions required, I'm happy to provide more information,, Just looking for clues really as the log isn't overly descriptive

Re: Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs

PhoneBoy — Mon, 06 Jul 2020 14:54:36 GMT

That's more than sufficient for my purposes 🙂
What some customers do is "exclude" this traffic from encryption, which is a setting in the VPN community.
And there appears to be bug related to this in R80.40 with Route-Based VPNs.
However, it sounds like you want IPsec in IPsec in this case.
A TAC case will most likely be required to troubleshoot this.

Re: Double encryption - hosts in spoke networks want to form IPSec over our route based VTIs

IanS94 — Tue, 07 Jul 2020 23:20:05 GMT

Just posting for reference here in case people are looking for this in future

We had a call with TAC who highlighted sk106241

Of course, this could be determined to be the relevant solution for particular issues people looking at this are seeing, although nothing should be taken as a given, and the fix/issue for us may not be the exact fix/issue for you etc - always check first I guess.

The logs are no longer displaying dropped and the "Failed to enforce VPN policy (11)" error, and we'll be testing it tomorrow when resources are available to test. We went with the temporary (until reboot) version for now, and will throw in the permanent global variable should this be proven to resolve the issue.

Thanks for your assistance here, has been good to confirm it's not just me missing something obvious