VPN Domain Explanation
Complex default behaviors and non-industry-standard implementation of encryption domains causes a lot of issues with interoperable VPN (VPNs with different vendors). Not to mention general confusing nature of their VPN domain implementation. This FAQ’s purpose is to attempt to clarify this behavior and be a consolidated resource for Check Point’s VPN domain information.
VPN Domain is also known as encryption domain, proxy-ID, and cryptomaps (some received IKE messages may simply refer to them as “ID information”).
Per VPN101, encryption domains are the local and remote networks, which are negotiated as part of the IKE Phase 2 negotiations, in order to “better” secure the use of the VPN tunnel to permit only those networks, and (in Check Point’s case) as a routing mechanism. As stated earlier, there is some behavior differences in Check Point’s implementation of these that make it a little more difficult to understand / work with. I have identified the prevalent 3 below:
VPN Domain Configuration
In many vendors this is implemented in completely different ways. For example; if you are using Juniper rule based VPNs, then the proxy-IDs are negotiated per the rules created (IE firewall rule source = local network, and destination = remote network); however, in a route-based configuration those proxy-IDs must be configured in that specific VPN’s configuration.
The industry standard is for encryption domian configuration to be on a per VPN basis. Check Point does not follow this practice, and it is that fact alone that creates many of the issues with domain configuration.
For example: Say you have a site-to-site VPN given the below configurations (note: please keep in mind that a local network to you is a remote network to the other site’s firewall):
Check Point firewall
hostname: Local-peer ; IP: 188.8.131.52
Local networks: 192.168.108.0/24 and 192.168.110.0/24
Random other vendor’s firewall with multi-enc-domain support
hostname: Remote-peer ; IP 184.108.40.206
Remote networks: 10.10.228.0/24 and 10.10.230.0/24
When setting up this VPN, the remote admin simply creates the profiles for VPNtoEx, and within those configurations, he finds the Encryption Domain portion and configures it appropriately.
When you set up ExVPN community, however, you go through the ExVPN Community properties window, thoroughly, but find no mention of encryption domains or any of its aliases.
In Check Point, in order to configure the VPN domains, you must edit the object that represents the firewalls for the 2 peers. You will find this in your Local-peer Check Point gateway object > Topology – “VPN Domain” section, and the Remote-peer interoperable device object > Topology – “VPN Domain”. The problem with this, is it creates one master VPN domain list for your firewall, that is used for ALL VPNs!
So what happens when you have 10 different networks (non-contiguous for now in order to simplify, see next section “Supernetting” for why) that have different VPN access requirements? For example, users from your 192.168.108.0/24 and 110 networks require access through ExVPN but not Ex2VPN; however, users from your 112 and 114 networks require access to your Ex2VPN but not ExVPN? If you add those four networks to your VPN domain group, and VPNs negotiate these networks then wouldn’t negotiations fail if you just porvide the necessary networks to the remote admin?
The answer is DEPENDS — on your VPN community configuration, specifically Community properties > Tunnel Management > VPN Tunnel Sharing. There are 3 options: Tunnel per host pair, tunnel per subnet pair, and tunnel per gateway pair. If you have the configuration as tunnel per “gateway pair” then yes, your VPN would fail to negotiate, as it would attempt to do so with all networks defined in the VPN domain group. 99% of the time, the configuration should be set to “per subnet pair”. Then when user from your 108 network attempts to connect over ExVPN to a server in the remote 228 network, then a tunnel is created with the phase 2 negotiating 192.168.108.0/24 as local network and 10.10.228.0/24 as remote network, and as Remote-peer has both of these networks configured, the negotiation will be successful. But when a user from 110 connects to 228, then there is a second tunnel created by negotiating that subnet pair.
Note: Setting this to per “host pair” is equivalent to disabling encryption domain negotiation for this VPN (but that doesn’t mean you can not configure VPN domains, see Routing for why it is necessary for remote domain, and Interesting Traffic for why it is necessary for local), but this will create SPI’s for EVERY different client to different server communication, which can create an extremely heavy load on the firewall as it has to track each tunnel as such. There is certainly valid business reasons to set it to host to host, but “because Phase 2 would never negotiate domains, correctly” is not one of them. For example… Note that this sk has the remote side config as “Tunnel Sharing is configured for host based VPN”, so I’d assume the remote admin had a necessity to leave it that way (ask maybe they don’t, maybe you are their only VPN). IKE debugs (see linked FAQ) will be helpful in sorting out domain negotiation issues.
This operation becomes further complicated when you incorporate the following additional considerations:
Vendors use different mechanisms to establish how to route VPN destined traffic. Many vendors have 2 options for setting up a VPN because of this. 1) Route-based, which simply uses the system’s routing table to send traffic through some kind of virtual tunnel interface, and that interface (which appears to be a normal interface to the system) acts as the VPN tunnel’s entrance. 2) Policy, or rule, based, which requires a rule to be created that references a specific VPN, and once that rule is matched by a connection, that connection is directed to the VPN.
Check Point utilizes what is called a “Domain-based” VPN… IE they utilize the domains to route the packets through a tunnel. For example if packet with source IP of 192.168.108.121 and destination IP 10.10.228.19, then first it’ll check VPN domains, where it matches VPN domains for source VPN domain Local-peer and destination Remote-peer, then it’ll check to see if these gateways share a VPN community; if so then forward through ExVPN (related tunnel as those domains are negotiated, or negotiate a new IPsec tunnel). Because of this implementation, instead of a rule-based type, you can have rules that have VPN set to “Any” but the system will still know to send traffic destined for a remote site over a specific VPN. It is also because of this that overlapping encryption domains will likely cause unexpected behaviors. Use the command ‘vpn overlap_encdom’ to display any overlapping encryption domains.
Check Point does have a route-based VPN option (dependent on OS used for the gateway), but the caveat here is that the Domain-based checks HAPPEN FIRST, before checking the system OS. In all of their intelligent glory, Check Point decided to use that domain function to disable itself. Per the admin guide, to disable the Domain based checks, and use route-based VPN, you must set the VPN Domain of the security gateway too an “empty group object”, effectively changing the encryption domain to 0.0.0.0/0… This has been known to break interoperable and externally managed Domain based VPNs (though I haven’t seen enough of this to confirm it). AFTER ENSURING CONFIGURATION ON BOTH SIDES IS CORRECT. if issue persists, you should be able to mitigate IPsec domain negotiation issues by defining specific domain negotiations in user.def per this SK SOLUTION A – 2.
Interesting traffic is the traffic that is defined as route-able through a VPN. This certainly seems redundant to routing, and as such, most implementations use the same routing mechanism as the initial interesting traffic check as well. Some vendor’s, however, utilize a separate ACL or such to identify interesting traffic. Checkpoint utilizes it’s VPN domain configuration to identify interesting traffic for any VPN for the entire gateway. How is that different than routing, you ask? Routing is determined by the combined local and remote encryption domains compared to the existing / possible IPsec tunnels, when the packet is ready to be routed. But when a local packet first hits the firewall, this packet will not even be considered for the VPN process if that packet does not match a local VPN domain.
For example: Let’s say the remote admin for Remote-peer of ExVPN has local networks that conflict with your local 108 and 110 networks. As such they request that you NAT these to public IP addresses (this is a common practice). You decide that business requirements allow you to use Hide NAT, so you set both networks to NAT the source address to 220.127.116.11. You create node object representing 18.104.22.168 and add it to the VPN Domain group. You require that 108 remains in the group for a different VPN, but you no longer need to negotiate the 110 network as an encryption domain, so you remove it. You do not need to change your firewall policy (due to hide NAT occurring after firewall policy). Users from 110 will report issues with access over the VPN, while users from 108 will not have issues. You check key install logs (per linked FAQ) and you find Quick mode completes between only 22.214.171.124/32 and 10.10.228.0/24 (you left tunnel management as per subnet pair, so this is the expected negotiations), then you check the outbound 110 traffic logs to find this traffic dropped by the “Cleanup” rule (it can also be dropped by anti-spoofing if it attempts to forward outbound traffic permitted by a general outbound rule, as it has destination of internal IPs if anti-spoofing is configured correctly, or it can be permitted by a general outbound rule if it is not, but it will not be an “encrypt” action log, just permit) instead of being permitted per your rule that has VPN set to anything other than ‘any’. To resolve, add 110 back to the VPN Domain group. Then, even though it will not create a new tunnel for it, it will be considered for the VPN and NATted then routed appropriately.
Incoming traffic, with a private IP address, regardless of being over a VPN and regardless of VPN domain configurations, is checked by the Check Point’s Anti-spoofing security. You may need to add the remote networks to the anti-spoofing topologies as appropriate (if it is coming through an “External” interface, then you must add the networks or groups of networks to the “Don’t check packets from” of that interface’s Anti-spoofing settings).
This default behavior I find to be very annoying. Check Point will automatically attempt to supernet VPN domains. For example, lets say you have a need to turn-up a new VPN (Ex3VPN) and your 192.168.109.0/24 and 192.168.111.0/24 networks require access through it. You configure everything exactly as needed, like ExVPN (disregard NAT configuration in the example for “Interesting Traffic” section), and push policy. Suddenly, all users from 108, 109, 110, and 111 now report they cannot access the remote resources through their perspective VPNs. You find SV Tracker logs that indicate Quick mode does not complete, and their are IKE messages received from the peer stating “invalid ID information” (or invalid proxy-ID, etc…). You run IKE debugs (per linked FAQ) and upon review you will find that both ExVPN and Ex3VPN are now attempting to negotiate the network 192.168.108.0/22 as your local network.
You just got SUPERNETTED! The fact that they do this as default isn’t so bad until you consider that they have only ONE MASTER VPN Domain list for your local networks. Easy work around would be to have the remote admin set the encryption domain to that /22 network… BUT it is not hard to resolve per this SK SOLUTION A-1 (though the SK reads like you must do all solution A steps to resolve, this is not the case, and I have confirmed via labbing it — Just change the ike_use_largest_possible_subnets with dbedit)(if you have not used dbedit in the past, I suggest you familiarize yourself with it via lab before attempting to use it on production equipment).
Peer IP Included in VPN Domain:
Finally, and probably oddest of all, is that peer IP addresses (the main IP address that is configured on the “General Properties” page of any gateway / interroperable object) is included in that object’s encryption domain. This is mainly noteworthy if you a) attempt to use “Tunnel per gateway pair” tunnel management, or if during troubleshooting an issue, you or the remote admin try to ping each others gateways directly. The former will fail for interoperable VPNs (any 3rd party as CP is the only vendor who practices this), if your remote admin does not include their peer IP in their local domains, and your peer IP address in the remote domains for this VPN. The latter may cause some confusion when you are looking through SmartView Tracker at the key exchange logs, as it will generate “recieved clear-text packet that should have encrypted” (if remote peer attempts direct communication outside of the VPN) and/or some kind invalid ID messages as the Check Point gateway will try to build a tunnel for that subnet (peer IP to peer IP as the negotiated encryption domains)(local peer attempts direct communication with remote peer). To avoid confusion, use IKE debugs to determine which IKE/IPsec messages belong to which subnet pair.