Configuring IPsec
udp 0 |
0 |
193.110.57.17:4500 |
0.0.0.0:* |
|
udp 0 |
0 |
193.110.157.17:4500 |
0.0.0.0:* |
|
udp 0 |
0 |
127.0.0.1:500 |
|
0.0.0.0:* |
udp 0 |
0 |
193.110.57.17:500 |
0.0.0.0:* |
|
udp 0 |
0 |
193.110.157.17:500 |
0.0.0.0:* |
|
udp 0 |
0 |
::1:500 |
:::* |
|
You can see both the regular IKE port (on UDP 500) and the NAT-T IKE port (on UDP 4500). The last entry shows an IPv6 localhost address.
Dead Peer Detection
Sometimes a VPN tunnel may die without detection, for example if one of the two peers crashes and reboots. If you add NAT and NAT-T into this picture, it becomes even more complex. If some IPsec tunnel has very low traffic, a NAT device in the middle might decide this connection has gone away, and drop its translation entry for it. Now both peers think the IPsec connection is up, but when one of them tries to send a packet, it finds the VPN has silently vanished.
With unencrypted connections, such connections would simply fail on their first packet, since the remote host would send an ICMP message about the (for the remote end) unknown connection.
With IPsec this becomes harder, as the peer that didn't get rebooted cannot just trust any unencrypted ICMP message from the other end.
With the uniqueid=yes option set, which is the default for Openswan, the rebooted end can establish a new tunnel, and since all tunnels are considered unique, the stable end of this connection will terminate the old connection when it establishes the new connection. Unfortunately, not all hardware vendors act in the same way. Some may plainly refuse to speak unencrypted to the rebooted peer to even allow it to establish a new connection until the current keylife has reached its end, and rekeying that connection has failed. Others might want to find out a tunnel is dead before any traffic is lost, such as an IPsec connection for a payment terminal. There is hardly any traffic, but once there is, you really want the tunnel to work and not find out at the most awkward time that the tunnel is indeed down. DPD makes this possible.
DPD also has the additional benefit of preventing NAT timeout, since the connection isn't idle for long periods due to the DPD testing packets.
Another use for DPD is to allow large-scale VPN servers to kill off VPN connections for which the other end has vanished. Common scenarios for this include a user accidentally pulling the phone line out of their laptop, a wireless network that just lost its connection, or a GPRS connection failure when hopping between GSM cells. There are many reasons why a connection can suddenly stop uncleanly without the other end knowing that you have dropped off the network. Especially for big VPN servers, you do not want to have too many of these dead connections hanging around.
This is of course a classic problem, and has been solved before. Just send a keep alive packet once in a while when there is no other traffic. If no response is received for a certain time, the remote peer is considered dead and the connection is torn down.
98
Chapter 4
Though purists find this a bad protocol design and will call these packets make deads because in some scenarios these keep alive packets can kill a perfectly fine connection if the packets are lost somehow. One very common scenario is one where the uplink is congested, and some packet loss is bound to happen. If the packets dropped because of the congestion happen to be the keep alive packets, the entire connection will soon find itself terminated.
Do not use Dead Peer Detection on congested links.
DPD Works Both Ways
It is important to realize that DPD is not the same as other keep alive packets. If both IPsec peers have announced their DPD capability, it does not mean that DPD is activated. The choice of whether a certain connection should have DPD protection enabled is made independently by both ends. The big VPN gateway for instance can decide it wants to know about these clients, but it does not need to know this every 5 minutes. It could decide to check client connections every 3 hours. While for our cash terminal, it might be decided the IPsec connection is so important that it warrants a DPD check every 30 seconds.
It can also be that one of the two ends doesn't care about whether the other end goes away (for instance a roadwarrior). Therefore, each end can decide if and how often it wants to send DPD packets. The only rule for all is that if you announce (through the VendorID) that you are capable of DPD, then you must answer all DPD packets from the other end, even if you yourself do not care about DPD and do not send any DPD probes.
Configuring DPD
Openswan always announces its DPD capability, and will always respond to DPD requests from remote peers. It does not enable sending DPD requests by default. If you are interested in sending DPD requests, the following parameters need to be added to the connection:
dpddelay=30
dpdtimeout=120
dpdaction=hold
The example lists the default values. For static tunnels, dpdaction= should be set to hold or restart. Hold will ensure no packets will flow in the clear until the tunnel comes back online. Restart will cause the connection to be restarted, as if you had typed ipsec auto –up connname. For roadwarriors, you want to use a dpdaction=clear on the server end to forget this entire connection, since roadwarriors might be gone for long periods of time and show up on a different IP address later.
You will see two extra messages in the log files confirming the other end supports DPD when the IPsec connection establishes:
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: initiating Main Mode
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: received Vendor ID payload [Dead Peer Detection]
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: transition from
99
Configuring IPsec
state STATE_MAIN_I2 to state STATE_MAIN_I3
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: Peer ID is ID_FQDN: '@roadwarrior'
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #10: ISAKMP SA established
Sep 22 11:59:02 roadwarrior pluto[15377]: "sunset-rw" #11: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#10}
Sep 22 11:59:03 roadwarrior pluto[15377]: "sunset-rw" #11: Dead Peer Detection (RFC 3706) enabled
Sep 22 11:59:03 roadwarrior pluto[15377]: "sunset-rw" #11: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Sep 22 11:59:03 roadwarrior pluto[15377]: "sunset-rw" #11: sent QI2, IPsec SA established {ESP=>0x2cc3429d <0xb2004c39}
And every 30 seconds, you will see DPD IKE packets:
12:36:32.636308 194.109.83.36.isakmp > 193.110.157.131.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:36:32.636721 193.110.157.131.isakmp > 194.109.83.36.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:02.633520 193.110.157.131.isakmp > 194.109.83.36.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:02.642014 194.109.83.36.isakmp > 193.110.157.131.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:02.642365 193.110.157.131.isakmp > 194.109.83.36.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:02.644539 194.109.83.36.isakmp > 193.110.157.131.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:32.649015 194.109.83.36.isakmp > 193.110.157.131.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
12:37:32.649370 193.110.157.131.isakmp > 194.109.83.36.isakmp: isakmp: phase 2/others ? inf[E]: [|hash] (DF)
Notice how the first exchange was initiated by the Roadwarrior, while the second exchange was initiated by West. This is the result of adding the DPD parameters to both sides of the connection, and using the same (default) parameters. To avoid this, you can pick a different dpddelay= setting, or you could decide not to configure DPD on the roadwarrior.
Buggy Cisco Routers
There is a known bug in some Cisco routers, which send incorrect DPD packets with a broken rcookie in the R_U_THERE packet. Normally, these packets are dropped by Openswan, and a message is logged:
Sep 22 13:43:05 dev pluto[1888]: "to-cisco" #23: R_U_THERE_ACK has invalid rcookie
Sep 22 13:43:05 dev pluto[1888]: "to-cisco" #23: sending notification INVALID_COOKIE to 1.2.3.4:500
And after the time specified in dpdtimeout=, the connection will be torn down:
Sep 22 13:43:07 dev pluto[1888]: "to-cisco" #23: DPD: No response from peer - declaring peer dead
Sep 22 13:43:07 dev pluto[1888]: "to-cisco" #27: deleting state (STATE_QUICK_I2)
Sep 22 13:43:07 dev pluto[1888]: "to-cisco" #26: deleting state (STATE_QUICK_I1)
Sep 22 13:43:07 dev pluto[1888]: "to-cisco" #23: deleting state (STATE_MAIN_I4)
100