cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
XBensemhoun
Silver

Domain Based VPN take precedence over any other type of routes

Because I didn't find an explicit description of the following situation, I've decided to share it here.

sk109340‌ "Mixing Route Based VPN with Domain Based VPN on the same gateway" describes the implementation of both Route Based VPN and Domain Based VPN.

We understand that "Domain Based VPN will take precedence over Route Based VPN for conducting the VPN traffic (...)".

I would like to generalize : Domain Based VPN will take precedence over any other type of routes (static routes, dynamic routes and off course: routes of a Route Based VPN - if the connection's source and destination are included in the gateway's encryption domains and both gateways are included in the same VPN community).

The following point is regarding the IP used from the firewall to consume some services (such as ldap, dns, ntp, …) through VPN.

There is no equivalent on Gaia of the well known parameter : this IP is determined by the routing table in the OS, using the egress interface IP as the source IP (thanks to https://community.checkpoint.com/people/dwelccfe6e688-522c-305c-adaa-194bd7a7becc inCheckpoint firewall logging source interface).

That said : if, for any reason, you add a static route to a local 3rd level equipment (one or all of RFC1918 for example) whereas the resource you're trying to reach is reachable through the VPN, the firewall will use its LAN address and not its External.

1 Reply
XBensemhoun
Silver

Re: Domain Based VPN take precedence over any other type of routes

And the sk109340 Mixing Route Based VPN with Domain Based VPN on the same gateway has been modified so that it's more clear:

Note: The routes used for Domain Based VPN are implemented after the regular OS routing table (due to "reroute_encrypted_packets" value in GuiDBedit). Consequently, any regular route that is integrated into the OS routing table will be overwritten (Dynamic, Static etc.). 

Thanks David Kornfield and the SecureKnowledge Team.