Encryption failure: failed to enforce VPN policy (10)

[mjovovic]

Hi, 

Just had situation on our CP R80.40 firewall cluster, which suddenly stopped encrypting interesting traffic to the most important S2S VPN tunnel (without any change in configuration). 🙄

FW VPN policy rules just were not enforced when packets arrived to fw kernel, with defined source subnets to destination peer subnets as in VPN rule. No IKE packets were sent to PEER side at all, could not find the real reason in IKE.elg and IKEv2.XML debug files in which PEER public IP did not appear at all.

What is more, all other VPN tunnels continued functioning perfectly. 

We had an issue with following encryption error - failed to enforce VPN policy (10):

We could not find any SK for this particular failure reson. There is another sk for failed to enforce VPN policy (11) which is not about this problem. We applied kernel parameter from this sk-  fw ctl set int encrypt_non_gw_rdp_ike 1  but without help.

15 days back this cluster was upgraded from R80.10 to R80.40 version, and all were functioning as a charm without any problems till today. 

I knew that this has something to do with encryption domain for this particular VPN traffic. But do not know how all other vpn tunnels worked which all used local encryption domain defined according to GW/cluster object VPN domain definition (VPN domain common group for all VPN's).

As R80.40 allows defining local encryption domain per VPN tunnel, we made change to only this tunnel and immediatelly tunnel went back in UP and RUNNING state. 

Kindly ask You for information is there a better wayt to deal with this kind of situations, to find the real reason why traffic is not encrypting and is going in clear instead, when at the same time in VPN debug can not find wanted VPN logs, because traffic were not encrypted at all?  Is there any SK which can help us for this error failed to enforce VPN policy (10)?

Regards,

Milos

[Timothy_Hall]

Something in your firewall's VPN domain (or a peer's VPN domain) changed and caused an overlap with one or more of your remote peer sites, which was then solved by using the R80.40+ per-community VPN domain setting.  This type of problem can happen inadvertently if someone changes an object which is nested in a group referenced in your firewall's or a peer's VPN domain.  That error message just means policy can't be enforced properly because the firewall cannot conclusively link the traffic to one (and only one) VPN Community.

Try running command vpn overlap_encdom communities –s and see if it detects any VPN domain overlaps between your site and a peer, or even between multiple peers.

[mjovovic]

Hi Timothy, thanks for Your comment.

We have same management server which manages both -  central cluster and DR FW (on two different sites). This management database have defined two different security policy sets (DR and central). We Have most crytical VPN's (including this particular one) defined on DR site policy too. For this purpose we use Two different interoperable devices with same IP for DR and central policy.

This particular app traffic (which goes through this VPN tunnel) was migrated 2 years ago from old VPN tunnel to NEW one. Old vpn tunnel policy rules and objects (interoperable devices, communities,..) are disabled not deleted. New VPN tunnel has different PEER IP.

We have overlapping encryption domains for central cluster and DR fw interoperable device objects, because those interoperable device objects are created with same IP but are used in different security policies. This is legacy from old FW policy and maybe it is best to use same object for both policies? No overlapping encryption domains for this vpn tunnel which was problematic on central site.

[Expert@cpgw1:0]# vpn overlap_encdom communities
The objects Host_vpn_to_Asseco_Developers_novo and Host_vpn_to_Asseco_Developers have overlapping encryption domains.
The overlapping domain is:
x.x.x.x-x.x.x.x

y.y.y.y-y.y.y.y

Only one subnet is overlapping. Two different VPN'S all are active and used (different interoperable device IP).

- Host_vpn_to_Asseco_Developers_novo is an interoperable device, multiple entry points configuration with interoperable device is not supported. - what does this mean?
- Same destination address can be reached in more than one community (Community_vpn_to_Asseco_Developers, Community_vpn_to_Asseco_Developers_novo). This configuration is not supported.

The objects SIA_VPN_GW_CheckPoint_DR and Host_DR_VPN_KBBLDR_FD have overlapping encryption domains.7

Host_DR_VPN_KBBLDR_FD is not used/disbled.

The overlapping domain is:
x.x.x.0 - x.x.x.255
y.y.y.0 - y.y.y.55
z.z.z.z - z.z.z.z

- SIA_VPN_GW_CheckPoint_DR is an interoperable device, multiple entry points configuration with interoperable device is not supported.
- Same destination address can be reached in more than one community (Community_DR_VPN_KBBLDR_FD, SIA_DR_VPN_Community). This configuration is not supported.

[mjovovic]

Hi Timothy,

Thanks for Your comment.

We have some legacy from previous FW solution,that for DR policy we use different objects (different names with same IP address).  This is shown in vpn overlap_encdom communities output. Those objects are used in separate policy sets. Maybe this is not good practice, maybe we should use same objects in both policies?

This particular VPN tunnel traffic was migrated from old VPN tunnel 2 years back. VPN rules for old VPN tunnel are disabled not deleted. 

Maybe this all had impact on encryption domain problem which suddenly arose without change on both sides.

[the_rock]

Hi Milos,

Timothy I believe is on the right track. I also found below forum (I know its from ages ago : -), but it seems to reference similar thing.

https://www.cpug.org/forums/showthread.php/4673-encryption-failure-failed-to-enforce-VPN-policy

[mjovovic]

Hi the_rock,

Thanks for URL share, where remote/peer encryption domain modification resolved an issue.

We modified local encryption domain to per VPN tunnel not as defined on GW/cluster level. And after that we 've summed up the remote encryption domain (group on topology tab in interoperable device) to only peer NAT subnet.

Not sure which part helped here.

Ones more, this was functioning without any problems for years back. 🙂