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.

JunOS Configuration

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:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127


interfaces {
	gr-0/0/0 {
		unit 2 {
			# GRE tunnel
			tunnel {
				source 192.168.41.9;
				destination 192.168.41.10;
			}
			family inet {
				mtu 1476;
				address 192.168.42.9/30;
			}
		}
	}
	st0 {
		unit 2 {
			# IPSec Tunnel
			family inet {
				address 192.168.41.9/30;
			}
		}
	}
}
protocols {
	ospf {
		area 0.0.0.0 {
			# Local subnet that is advertised to remote sites
			interface vlan.200 {
				passive;
			}
			interface gr-0/0/0.2;
		}
	}
}
security {
	ike {
		proposal IKE-PROPOSAL-BRANCH3 {
			authentication-method pre-shared-keys;
			dh-group group2;
			authentication-algorithm sha1;
			encryption-algorithm aes-256-cbc;
			lifetime-seconds 86400;
		}
		policy IKE-POLICY-BRANCH3 {
			mode main;
			proposals IKE-PROPOSAL-BRANCH3;
			pre-shared-key ascii-text "branch3"
		}
		gateway IKE-GATEWAY-BRANCH3 {
			ike-policy IKE-POLICY-BRANCH3;
			address 192.168.39.14;
			external-interface ge-0/0/0.0;
		}
	}
	ipsec {
		proposal IPSEC-PROPOSAL-BRANCH3 {
			protocol esp;
			authentication-algorithm hmac-md5-96;
			encryption-algorithm 3des-cbc;
			lifetime-seconds 1800;
		}
		policy IPSEC-POLICY-BRANCH3 {
			perfect-forward-secrecy {
				keys group2;
			}
			proposals IPSEC-PROPOSAL-BRANCH3;
		}					
		vpn IPSEC-VPN-BRANCH3 {
			# Local IPSec tunnel interface
			bind-interface st0.2;
			ike {
				gateway IKE-GATEWAY-BRANCH3;
				no-anti-replay;
				proxy-identity {
					local 192.168.41.9/32;
					remote 192.168.41.10/32;
					service any;
				}
				ipsec-policy IPSEC-POLICY-BRANCH3;
			}
			establish-tunnels immediately;
		}
	}
	zones {
		security-zone INTERNAL {
			host-inbound-traffic {
				system-services {
					all;
				}
				protocols {
					all;
				}
			}
			interfaces {
				st0.2;
				gr-0/0/0.2;
			}
		}
		security-zone INTERNET {
			host-inbound-traffic {
				system-services {
					all;
				}
				protocols {
					all;
				}
			}
			interfaces {
				ge-0/0/0.0;
			}
		}
	}
	policies {
		from-zone INTERNAL to-zone INTERNAL {
			policy ALL {
				match {
					source-address any;
					destination-address any;
					application any;
				}
				then {
					permit;
				}
			}
		}
	}
}

EdgeOS Configuration

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80


interfaces {
	ethernet eth1 {
		description "INTERNET"
		address 192.168.39.14/30
	}
	ethernet eth2 {
		description "INTERNAL"
		address 192.168.37.1/24
	}
	loopback lo {
		address 192.168.41.10/32
	}
	tunnel tun0 {
		description "GRE tunnel over IPSEC"
		address 192.168.42.10/30
		encapsulation gre
		local-ip 192.168.41.10
		multicast enable
		remote-ip 192.168.41.9
	}
}
protocols {
	ospf {
		area 0 {
			network 192.168.42.8/30
			network 192.168.40.4/32
			network 192.168.37.0/24
		}
	}
	static {
		route 0.0.0.0/0 {
			next-hop 192.168.39.13 {}
		}
	}
}
vpn {
	ipsec {
		esp-group IPSEC-PROPOSAL-BRANCH3 {
			lifetime 1800
			mode tunnel
			proposal 1 {
				encryption 3des
				hash md5
			}
		}
		ike-group IKE-PROPOSAL-BRANCH3 {
			lifetime 86400
			proposal 1 {
				dh-group 2
				encryption aes256
				hash sha1
			}
		}
		ipsec-interfaces {
			interface eth1
		}
		site-to-site {
			peer 192.168.39.2 {
				authentication {
					mode pre-shared-secret
					pre-shared-secret branch3
				}
				connection-type initiate
				default-esp-group IPSEC-PROPOSAL-BRANCH3
				ike-group IKE-PROPOSAL-BRANCH3
				local-ip 192.168.39.14
				tunnel 1 {
					esp-group IPSEC-PROPOSAL-BRANCH3
					local {
						subnet 192.168.41.10/32
					}
					protocol all
					remote {
						subnet 192.168.41.9/32
					}
				}
			}
		}
	}
}