IPSec VPN’s are the de-facto standard for connecting multiple sites together over the Internet. Unfortunately, interoperability between multiple vendor’s IPSec implementations can be “fun”. IPSec leaves many options to individual implementations, so it can be somewhat configuration heavy. And multiple vendors don’t necessarily use the same terminology, configuration structures, or defaults, further complicating things.
There are a couple common different modes of operation for site to site VPN’s - policy based and route based. Coming from a network background, I prefer to look at site-to-site tunnels as just another L3 interface that the router routes over (meaning, route-based tunnels). In this scenario, which traffic is sent over the tunnel is controlled simply by routing. Many vendors' implementations are designed primarily for “policy-based” site-to-site VPN’s. Policy-based VPN’s typically select traffic with an access list that is applied to the physical interface (rather than the VPN tunnel being a separate interface). To me, this seems kludgy and less flexible. So, where possible, I prefer to use route-based tunnels, ideally with dynamic routing.
Route Based Advantages:
- Router uses routing table to select traffic for the tunnel, the same process that it uses to select traffic for all other interfaces. This makes troubleshooting easier.
- Possible to use dynamic routing protocols
- Easy to route multiple subnets through tunnel. No config changes even necessary on tunnel itself if using dynamic routing. With policy based tunnels, this may change proxy identities which could interrupt the tunnel.
- Conceptually more similar to using private WAN connections
Route Based Disadvantages:
- Potentially more configuration needed upfront
- Interoperability can be more complex
JunOS to Vyatta / EdgeOS
IPSec in Vyatta appears to be primarily intended for policy-based tunnels. But, if the VPN endpoints also support a common cleartext tunneling protocol (like GRE), you can create a route-based VPN by running GRE over a policy-based IPSec tunnel. I used a Juniper SRX 210 and a Ubiquiti EdgeRouter Lite in this scenario. Ubiquiti’s EdgeRouter series of products run their EdgeOS software, which is based on Vyatta.
On the JunOS device, the IPSec VPN tunnel is configured between the Internet facing interface (ge-0/0/0.0), and the Internet IP on the EdgeOS device (192.168.39.14). It is a route-based tunnel that attaches to the st0.2 interface. The st0.2 interface must be a part of a security zone. If it is not configured to be part of a security zone, you will see a somewhat misleading sounding error message stating that no proposal was chosen. Juniper has a KB article on this.
One other important thing to note is the proxy-identity configuration. This must always match between the IPSec endpoints (with the local / remote IP’s flipped). JunOS makes this easy in that it gives you the option of explicitly configuring the proxy-identity values. Many other implementations make implicit assumptions about what these values should be, based on what traffic you have selected for tunneling when using a policy-based tunnel. The proxy identity values themselves have no control over what traffic is routed through the tunnel. But many implementations set their proxy identity value based on that. Mis-matching proxy-identities are a fairly common problem when doing IPSec between different vendors. In this case, I am using the IP’s on the IPSec tunnel (192.168.41.9 / 192.168.41.10). I had to use these IP addresses, because the EdgeOS device automatically sets the proxy-identities on its side to match the networks that are routed through the tunnel.
In addition to the st0.2 interface, a GRE tunnel has been configured. The GRE tunnel endpoints are configured to be the addresses on the IPSec tunnel. The GRE tunnel itself is configured with a /30 network that will be used for routing. OSPF has also been enabled on the GRE tunnel.
So, here’s what happens when the SRX sends traffic to the 192.168.37.0 / 24 subnet at the remote branch:
Routing table lookup occurs - next hop is 192.168.42.10, accessible through the gr-0/0/0.2 interface. This route was learned via OSPF.
The SRX encapsulates the packet in GRE, and does a routing table lookup for the GRE tunnel’s endpoint - 192.168.41.10. That IP is accessible through the st0.2 interface (it’s on the same /30 that has been configured on st0.2).
The st0.2 interface is an IPSec tunnel (IPSEC-VPN-BRANCH3). So, the SRX encrypts the packet via IPSec, and sends it through the IPSec security-association that was established between the JunOS device and the EdgeOS device.
This IPSec encrypted traffic is forwarded to 192.168.39.14 (the Internet facing IP address on the EdgeOS router). This follows a static default route out to 192.168.39.1 via ge-0/0/0.0.
JunOS Config Text:
On the EdgeOS device, the IPSec tunnel is configured between the local Internet address and the Internet address of the JunOS peer. The EdgeOS device uses a policy-based tunnel. It selects traffic for the tunnel based on the local and remote subnets configured on the tunnel itself. These options both select traffic for the tunnel, and set the proxy-identities for the IPSec association.
The EdgeOS router doesn’t have an IPSec interface configured like the JunOS router does (st0.2). However, I have configured a loopback address (192.168.41.10 / 32) that overlaps with the subnet used on the IPSec tunnel interface on the SRX. This is needed so that we have an IP address to terminate the GRE tunnel that is sent through the IPSec tunnel. Using the /32 address on the loopback will work fine here - we don’t actually want to pull traffic for the remote router into the loopback interface. That traffic will match the policy configured for the VPN, so we don’t have to do anything specific to handle routing to 192.168.41.9. We need a /30 on the JunOS side though (192.168.41.9 / 30 ), because in that case we **do **want to pull traffic in to that interface, since it is an IPSec tunnel interface. There is no policy on the SRX that selects traffic for the tunnel (it relies on routing).
The GRE tunnel (tun0) is configured with the local loopback interface as one endpoint, and the IPSec tunnel interface as the other endpoint. Again, a /30 is configured on the GRE tunnel here, and OSPF is enabled.
Here is what will happen when the EdgeOS router sends traffic to the 192.168.33.0 / 24 subnet at the HQ:
Routing table lookup occurs - next hop is 192.168.42.9, accessible through the tun0 interface. This route was learned via OSPF.
The router encapsulates the packet in GRE, and does a routing table lookup for the GRE tunnel’s endpoint (192.168.41.9). It ends up matching the default route, but that doesn’t really matter - because it’s selected for the IPSec VPN tunnel based on the remote subnet that was configured.
The EdgeOS router encrypts the packet via IPSec and sends it through the IPSec security-association between the EdgeOS router and the JunOS router.
This IPSec encrypted traffic is forwarded to 192.168.39.2 (the Internet address on the JunOS router), following a default route out to 192.168.39.13 via eth0.
EdgeOS Config Text: