- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
This is gonna get really nitty-gritty detailed, and more than you're asking, but the core answer for "how does the firewall know to do VPN?":
* There is a function inside the VPN code called "VPN tagging"
* This function only gets triggered *AFTER* a packet passes through the routing table (via a "route lookup layer") and begins to egress an external interface
* VPN tagging (in general) only occurs on an external-facing interface (your eth1)
* The VPN tagging function does a bunch of work to figure out what kind of VPN to use (domain-based, route-based; and this is the part where domain-based VPNs override route-based VPNs)
* The VPN peer must also be reachable out an external interface to trigger the IKE process.
* Remote VPN domains and peers must NOT be within the internal network (including anti-spoofing configurations on the interface). That's because "VPN" by definition is "something external to the local gateway".
The VPN domain (encryption domain) does tell the local firewall what to encapsulate toward the remote peer, but the problem is that a packet is not going towards a remote peer. The packet is simply returning back to your local network.
Yes, more-specific routes win, but you don't have a more-specific route for 10.59.78.0/24.
Go to the command line of your firewall and run "ip route get 10.59.78.2" and it will show you "via 10.59.40.9 dev eth4" when you (likely) want it to go via eth1.
See the attached screenshot of your routing table.
If you must have this routing table, then you need to add a more-specific static route for 10.59.78.0/24 via 10.57.0.9. This will trigger the VPN code and start IKE towards the remote peer. Hence, the packets will be "tagged" for VPN; "untagged" packets are passed in plain text. Plain text packets are logged in the traffic log as an "Accept" log type. "VPN tagged" packets are logged as "Encrypt" (or "Decrypt", if the packet is being received).
(hint: you can do this same route trick for Remote Access VPN office-mode subnets, and once a route is in the FIB of the gateway, you can select it for redistribution to dynamic routing protocol)
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY