[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