From the beginning of mankind, the users have wanted to communicate securely and to protect sensitive information.
With modern society where everything is digitized, this need for protection when it comes to computer network communication is fulfilled by Virtual Private Network (VPN).
One of the most used protocols to build a VPN is Internet Protocol Security (IPsec).
In this article, we will cover the LAN to LAN (Site to Site) VPN and we will focus on the difference between policy-based and route-based IPsec tunnels. Many network administrators are building VPN tunnels without understanding the difference between the two of them.
Today, the majority of IPsec VPN implementations utilize policy-based tunnels. This is happening because many vendors have only recently started adding support for route-based. For example, Cisco ASA added support for route-based VPN in version 9.7.1.
The main difference between policy-based and route-based VPN is the encryption decision:
- For policy-based VPN there are firewall policies that have “encrypt” as an action. Any traffic that matches this policy gets encrypted.
- For route-based VPN a virtual tunnel interface is created which logically represents the VPN tunnel. Any traffic that is routed towards this interface will be encrypted and sent across the tunnel. Either dynamic or static routing can be used to achieve this requirement.
IPsec Negotiation
In order to establish an IPsec tunnel, two phases of negotiation are required:
- In Phase 1, the participants authenticate the IPsec peers and establish a secure channel in which to negotiate the IPsec security associations (SAs). The outcome of the Phase 1 negotiation is the ISAKMP SA (Phase 1 SA) which besides other parameters has a lifetime. This lifetime should be longer than the phase 2 IPsec SA lifetime.
- In Phase 2, with the keying material derived from the phase 1 negotiation, the participants negotiate the IPsec SAs for encrypting and authenticating the exchanges of user data that will follow the negotiation.
In order to decide what protection will be provided for an outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the security association database (SADB), along with the destination address in a packet header, which together uniquely identifies a security association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the security association database.
Policy-based
In a policy-based implementation, an IPsec SA will be created for each combination of Local Encryption Domain (ED), Remote Encryption Domain (ED), protocol and port. Each IPSec SA created will be treated as a separate tunnel. Most implementations of policy-based IPsec only use a combination of Local ED and Remote ED. If for example we have in the Local ED one subnet and in the Remote ED three subnets, for phase two there will be 3 IPsec SA.
Now imagine a large enterprise with IPsec devices that hold hundreds of tunnels each with tens of subnets. These devices will need to use a lot of computational power to hold those IPsec SAs. Don’t forget the SAs have a lifetime (typically 3600 seconds) and once the lifetime expires there is a need to do a re-key.
Re-key is the event that is triggered for a SA that is about to expire: a new negotiation will take place and a new SA will be created. Once the new SA is negotiated, a notification message will be sent to the other peer with instructions to delete the old SA. The re-key doesn’t happen at the same moment for each vendor, this means that each implementation is different and the re-key can be triggered at different SA lifetime (for example a vendor can do the re-key at 80% lifetime of the SA and another vendor can do it at 90% of the lifetime).
Because you need a full phase 2 packet exchange, the re-key is hardware intensive for the IPSEC device and also for the network. In large enterprise networks that have a large number of subnets in their network, if all of the networks are inserted in the policy-based IPSEC configuration, a VPN tunnel will create a large number of phase 2 SAs which will need re-key.
Throughout the years there have been multiple draft IPsec documents from IETF that commented on RFC definitions and the problems that appear in real-life implementations. One such document can be found here: https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06
So basically there is a real burden to maintain a large number of SAs.
Route-based
In route-based implementations, the endpoints will negotiate: one ISAKMP SA (phase 1 SA) and one IPsec SA (phase 2 SA) and for each VPN tunnel will allocate a virtual interface (in some implementation are called VTI – virtual tunnel interface). In IPSEC phase 2 by default Local and Remote EDs are 0.0.0.0/0 (In Oracle implementation of route-based vpn the Local and Remote EDs are set to the default value and can’t be modified).
In order to encrypt a packet two condition must be met:
- A route for the remote network that points to the vti interface.
- The traffic that arrives at the vti must be included in the ED negotiated. If the default configuration is used, all the traffic will match the EDs (0.0.0.0/0)
Route-based VPNs show their versatility best when used for:
- Overlapping subnets or IP addresses between the Local and Remote ED.
- A hub-and-spoke VPN topology is used in the network, and spoke-to-spoke traffic is required.
- Primary and backup VPNs are required.
- A dynamic routing protocol (for example BGP) is running across the VPN.
OCI IPSEC Tunnels
In OCI, the entity that supports IPsec is called Dynamic Routing Gateway (DRG). The DRG only supports route-based and many built-in IPSEC solution in cloud services are more strict in customizing the configuration.
If the customer is using a route-based device we will have the following SPI
SPI for route-mode tunnels
- Source IP address: Any (0.0.0.0/0)
- Destination IP address: Any (0.0.0.0/0)
- Protocol: IPv4
Alternatively, a super-net can also be used for your SPI values instead of a default route as long as it remains a single entry.
If you’re using a policy-based device it’s possible to emulate a route-based setup with a single encryption domain by using Any (0.0.0.0/0) for local ED and the OCI VCN CIDR block as the remote ED. This can be a difficult challenge to digest because of the fear that all traffic, even for other VPN tunnels will go via the OCI VPN. This is totally wrong. Remember the SPI definition? You need Source ED, Remote ED in order to uniquely identify a SA. So in this case since the Source ED is 0.0.0.0/0, it will match everything, there is still Remote ED to disseminate the VPN traffic.
SPI for policy-based tunnels
- Source IP address: Any (0.0.0.0/0)
- Destination IP address: VCN CIDR (for example 10.0.0.0/16)
- Protocol: IPv4
As a conclusion, route-based IPsec tunnels are a far better choice in the current world and enables a smoother user experience and better resource management for both device and network (imagine the volume of packets that are needed in order to do the rekey).