Unwanted VPN Routing Between RA and S2S Communities

[Dave_Hoggan]

Hi,

I've been having a tough time trying to get something to NOT work and hoping that someone can suggest how I can achieve what I am trying to do.

The scenario is a HQ office and two data centres, each with a R80.xx cluster terminating VPNs. The three sites are connected by VPLS and routing handled by OSPF throughout the core network and up to the clusters. The preference is to keep all site-traffic over the VPLS unless there is an issue and then fail over to S2S VPNs. Because of this, there is a S2S VPN mesh community containing DC1, DC2 and HQ and each cluster has an encdom of only those networks local to the cluster (so HQ encdom is the HQ networks; DC1 encdom is the DC1 networks). Note: whilst the community is created, there are no access rules defined allowing traffic to pass between DC1, DC2 and HQ networks, not even a rule with a VPN column of "any".

We also have a RA community in first to respond MEP configuration. RA users can connect to DC1 or DC2 and be assigned an office mode address by the cluster. Users can then access resources local to the cluster to which they are connected.  The issue is that if a user connects to DC1 and tries to access a resource in DC2, the DC1 cluster attempts to VPN route the traffic over the S2S VPN which  (1) is not what we want and (2) does not work as there are no rules to permit the traffic. We want DC1 to route the traffic over the VPLS to DC2.

In the logs we see DC1 decrypt the remote access traffic and shows a source IP of the OM IP address. We then see a log entry from DC2 dropping the traffic on the cleanup rule (again source IP is the DC1 OM address, so no NAT is occurring). The interesting point is that an fw monitor on DC1 shows inbound packets arrive on DC1  with inbound chain "id" and "ID" and then outbound chain "o" and "O" on the interface connecting to the core router. So at this point all looks to be OK, but then we see the packet being sent over the S2S VPN on the external interface!

I think this is being caused by an implied rule 

Source: MemberGWs.EncDomain@MyIntranet

Dest: MemberGWs.EncDomain@MyIntranet

VPN: Any

Services: EncryptedServices@MyIntranet

Action: Encrypt&Continue

But cannot find any way to remove this implied rule. vpn_route,conf is blank and the communities "Accept all encrypted traffic" is not ticked, 

If I remove the destination network from the DC2 encdom, then traffic is passed over the internal network as expected, so it is definitely the S2S configuration causing the issue.

Can anyone see what I am missing?

Thanks,

Dave 

[PhoneBoy]

Perhaps configure the relevant interface as a “Trusted Link” so traffic exiting that interface isn’t encrypted?

[Timothy_Hall]

I don't think using VPN domains to specify what traffic should be encrypted (i.e. "interesting traffic") is going to be flexible enough for what you are trying to do here.  Check out using route-based VPNs via VTIs instead which combined with Dynamic Routing will do exactly what you want.  Route-based VPNs aren't heavily used on Check Point due to a longstanding incompatibility with CoreXL, but that limitation was removed in R80.10 gateway and later.

[Maarten_Sjouw]

Why are you using MEP for RA and not Secondary connect?
With secondary connect the client directly connects to the gateway that hosts the network in its own VPN Domain.
With Secondary connect however it keeps using the same OM IP it was aasigned by the first gateway it connects to, so all OM IP ranges need to be locally routed to the gateway.