12 Aug IPSec Security Associations behind DSL or Home Routers
Do you manage firewalls? Do you manage IPSec VPN tunnels? One situation you may run into is the need to create IPSec Security Associations (SAs) between 2 end points where one is behind a ISP provided router, usually managed. Let’s look at the following Layer 3 example:
There are a few things to point out. First, all the lines in the drawing are some sort of network connection. Second, I made one link RED for a reason. Notice how we have a DSL router in this drawing. We have the following interfaces we need to traverse in order to get to the Remote Office Firewall:
- DSL Router WAN: 188.8.131.52
- DSL Router LAN: 192.168.1.2
- Remote Office Firewall WAN: 192.168.1.1
Now in order to create an IPSec SA, we need to have 2 endpoints (commonly called IPSec gateways). The endpoint generally needs to be a public IP address that the Central Office Firewall can see over the internet. But since we have a managed DSL service, this presents a problem. The DSL Router can’t terminate an IPSec connection to our firewall. He can forward that request, (but it won’t work out of the box) but we need to play with some not always used IPSec options. Here they are:
On the Remote Office Firewall SA configuration you need to set up what’s called the IKE ID. For Phase 1, I am going to assume we are using Main Mode. You can get an overview of IKE Phase 1 here. In IKE Phase 1, there are 3 phases :
- First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.
- Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces—random numbers sent to the other party and then signed and returned to prove their identity.
- Third exchange: Verifies the other side’s identity. The identity value is the IPSec peer’s IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bi-directional. (Source: http://www.ciscopress.com/articles/article.asp?p=25474&seqNum=7)
The exchange we need to help finish is the Third exchange – peer matching. We use things such as IP addresses, serial numbers, and some other things (geek out over this here.) Let’s use an IP Address for the Phase 1 IKE ID. (There is also a Phase 2 IKE ID, but we aren’t talking about that)
We need to on each end define ONE possible value. There is a Peer IKE ID value and a local IKE ID value.
- On our association that we define on the Central Office Firewall, we need to set the Peer IKE ID to the WAN IP address of the FIREWALL WAN IP (192.168.1.1). We define the IPSec Primary/Secondary IP as the WAN IP of the peer (remote) router. (In this case 184.108.40.206)
- Next on our Remote Office Firewall SA, we define the Local IKE ID of 192.168.1.1, which tells him that it’s ok to allow the DSL Router to forward the IPSec traffic and NAT our VPN tunnel.
You may need to forward port UDP 4500 if you aren’t forwarding all traffic to your Remote office firewall.
By setting the IKE IDs (Peer and Local) we can allow a network device such as a home or DSL Router be our public facing device, but still initial gateway to gateway IPSec connections to connect networks together. This allows for using DSL or cheaper internet options for a second or redundant connection to your network in case your primary fails, or to use DSL or a manage device as your primary IP address.
Any suggestions to better explain this or any corrections are greatly appreciated.