[Swan] Problem with NAT and Dynamic IP address change

Tony Whyman tony.whyman at mccallumwhyman.com
Thu Jun 25 18:46:50 EEST 2015


I have recently upgraded from Openswan to Libreswan (1.13) on Ubuntu 
14.4 and there seems to be a problem with NAT and dynamic IP addresses 
that is a regression from Openswan (Ubuntu default version).

The scenario is a simple one, with a server on a fixed IP Address and a 
client system behind a NAT gateway on a dynamic IP Address.

The upgrade from Openswan went fine with the only issue being having to 
convert from the old style locations of certs and keys to NSS, and all 
continues to work fine until I get a dynamic IP address change, when the 
SA goes out of sync, communication is lost and cannot be recovered until 
I explicitly reset the connection on the non-NAT system. Automatic 
recovery is completely lost.

On the non NAT system:

conn ....
     authby=rsasig
     type=tunnel
     ike=3des-sha1;modp2048
     phase2alg=3des-sha1;modp2048
     dpddelay=30
     dpdtimeout=120
     dpdaction=clear
     left=<my ip>
     leftcert="alice"
     leftrsasigkey=%cert
     leftid=%fromcert
     rightca="my ca"
     right=%any
     rightsubnet=vhost:%no,%priv
     rightrsasigkey=%cert
     rightid="other cert - no wild cards"
     auto=add

and on the NATTED system:

conn defaults
     authby=rsasig
     type=tunnel
     ike=3des-sha1;modp2048
     phase2alg=3des-sha1;modp2048
     dpddelay=30
     dpdtimeout=120
     dpdaction=restart
     left=%defaultroute
     leftcert="bob"
     leftrsasigkey=%cert
     leftid=%fromcert
     rightca="my ca"
     right=server.domain.name
     rightrsasigkey=%cert
     rightid=" server's cert"
     auto=start

This all goes fine until the NAT gateway resets (we seem to get a line 
glitch about once a day at the moment) , and the dynamic IP address 
changes. Instead of this being recognised and recovered from (following 
RFC 3947),  the non-NAT system seems to get locked into a problem state.

With Openswan this scenario worked fine and the occasional time there 
was a problem it was sufficient to reset the connection from the NATTED 
system.

running ipsec auto status on the non NAT system gives

...
ENT_CRYPTO_FAILED in 3s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
000 #3931: "blackswan"[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting 
QI1); EVENT_CRYPTO_FAILED in 3s; lastdpd=-1s(seq in:0 out:0); idle; 
import:not set
000 #3930: "blackswan"[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting 
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle; 
import:not set
000 #3929: "blackswan"[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting 
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle; 
import:not set
000 #3928: "blackswan"[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting 
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle; 
import:not set
000 #3927: "blackswan"[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting 
QI1); EVENT_CRYPTO_FAILED in 1s; lastdpd=-1s(seq in:0 out:0); idle; 
import:not set
000 #1262: "blackswan"[5] 86.181.114.105:4500 STATE_MAIN_R3 (sent MR3, 
ISAKMP SA established); EVENT_SA_REPLACE in 630s; newest ISAKMP; 
lastdpd=2640s(seq in:22161 out:0); idle; import:not set

which seems to imply that the ISAKMP SA is up but there is a problem 
with the ipsec tunnel.

If I then enter

ipsec auto --down blackswan

I see

....
002 "blackswan" #7786: deleting state (STATE_QUICK_R0)
002 "blackswan" #7785: deleting state (STATE_QUICK_R0)
002 "blackswan" #7784: deleting state (STATE_QUICK_R0)
002 "blackswan" #7783: deleting state (STATE_QUICK_R0)
002 "blackswan" #7782: deleting state (STATE_QUICK_R0)
002 "blackswan" #7781: deleting state (STATE_QUICK_R0)
002 "blackswan" #7780: deleting state (STATE_QUICK_R0)
002 "blackswan" #7779: deleting state (STATE_QUICK_R0)
002 "blackswan" #7778: deleting state (STATE_QUICK_R0)
002 "blackswan" #4740: deleting state (STATE_MAIN_R3)
002 "blackswan"[5] 86.181.114.105: deleting connection "blackswan" 
instance with peer 86.181.114.105 {isakmp=#0/ipsec=#0}
002 "blackswan"[4] 86.181.114.105: terminating SAs using this connection
002 "blackswan" #38: deleting state (STATE_QUICK_R2)
005 "blackswan" #38: ESP traffic information: in=2708MB out=762KB
003 "blackswan" #38: ERROR: netlink response for Del SA 
esp.193d61d2 at 86.181.114.105 included errno 3: No such process
002 "blackswan"[4] 86.181.114.105: deleting connection "blackswan" 
instance with peer 86.181.114.105 {isakmp=#0/ipsec=#0}

The connection then comes back up again - as the other side is still 
"knocking at the door" - and communication is restored.

Any ideas on what is going wrong?

Tony Whyman
MWA






More information about the Swan mailing list