[strongSwan] What is expected "ipsec update" & "ipsec reload" behavior?

Ansis Atteka ansisatteka at gmail.com
Tue Feb 17 05:36:30 CET 2015


I am not sure that I understand "Currently established connections are not
affected by configuration changes." [
https://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand] wording
correctly for "ipsec update" and "ipsec reload" commands.
Does it try to say that, if IPsec tunnel was previously established and
then, if corresponding "conn" entry for that tunnel disappeared from the
ipsec.conf file, then after "ipsec update" call those tunnels would still
remain in the StrongSwan?


If yes, then how can I force strongSwan to remove those tunnels that are no
longer in ipsec.conf file?
1. Using "ipsec restart" command does not work for me because it makes all
tunnels to be renegotiated and causes unnecessary connectivity issues.
2. Using explicit "ipsec down <conn-entry>" call blocks if the peer is not
up (because of underlying IKE message exchange). This means that this
approach would not scale well if there are 1000+ tunnels, because each
"ipsec down" call could block for few seconds.


To see what I mean I am providing commands executed on both hosts:


root at ubuntu:~# cat /usr/local/etc/ipsec.conf

config setup
    uniqueids=no

conn %default
    keyingtries=%forever
    type=transport
    keyexchange=ikev2
    auto=route
    mark=1/1
    ike=aes128gcm12-aesxcbc-modp1024
    esp=aes128gcm12-modp1024

conn remote-1.1.1.12
    left=0.0.0.0
    right=1.1.1.12
    rightcert=/usr/local/etc/ipsec.d/ovs-1.1.1.12.pem
    leftcert=/root/client-cert.pem
    leftsubnet=%dynamic[gre]
    rightsubnet=%dynamic[gre]

root at ubuntu:~# ip xfrm state
src 1.1.1.11 dst 1.1.1.12
proto esp spi 0xc4799fd8 reqid 1 mode transport
replay-window 32
mark 1/0x1
aead rfc4106(gcm(aes)) 0x14f47887fef531156ecd9506eb1fc6cfd43dd62a 96
sel src 1.1.1.11/32 dst 1.1.1.12/32 proto gre
src 1.1.1.12 dst 1.1.1.11
proto esp spi 0xc370f38b reqid 1 mode transport
replay-window 32
mark 1/0x1
aead rfc4106(gcm(aes)) 0xe57364586ae7d5199b8cdf0c11e90dfcefdb76ae 96
sel src 1.1.1.12/32 dst 1.1.1.11/32 proto gre
root at ubuntu:~# ip xfrm policy
src 1.1.1.12/32 dst 1.1.1.11/32 proto gre
dir in priority 2818
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 1.1.1.11/32 dst 1.1.1.12/32 proto gre
dir out priority 2818
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0



And then I update ipsec.conf file to:

root at ubuntu:~# cat /usr/local/etc/ipsec.conf

config setup
    uniqueids=no

conn %default
    keyingtries=%forever
    type=transport
    keyexchange=ikev2
    auto=route
    mark=1/1
    ike=aes128gcm12-aesxcbc-modp1024
    esp=aes128gcm12-modp1024

conn remote-1.1.1.12-in
    left=0.0.0.0
    right=1.1.1.12
    rightcert=/usr/local/etc/ipsec.d/ovs-1.1.1.12.pem
    leftcert=/root/client-cert.pem
    rightsubnet=%dynamic[tcp/7471]
    leftsubnet=%dynamic[tcp/%any]

conn remote-1.1.1.12-out
    left=0.0.0.0
    right=1.1.1.12
    rightcert=/usr/local/etc/ipsec.d/ovs-1.1.1.12.pem
    leftcert=/root/client-cert.pem
    rightsubnet=%dynamic[tcp/%any]
    leftsubnet=%dynamic[tcp/7471]


and run "ipsec update". I still see that gre tunnel is up even though it is
not in ipsec.conf anymore:

root at ubuntu:~# ip xfrm state
src 1.1.1.11 dst 1.1.1.12
proto esp spi 0x00000000 reqid 2 mode transport
replay-window 0
mark 1/0x1
sel src 1.1.1.11/32 dst 1.1.1.12/32 proto tcp sport 0 dport 7471 dev eth1
src 1.1.1.11 dst 1.1.1.12
proto esp spi 0xc4799fd8 reqid 1 mode transport
replay-window 32
mark 1/0x1
aead rfc4106(gcm(aes)) 0x14f47887fef531156ecd9506eb1fc6cfd43dd62a 96 <----
old IPsec SA
sel src 1.1.1.11/32 dst 1.1.1.12/32 proto gre
src 1.1.1.12 dst 1.1.1.11
proto esp spi 0xc370f38b reqid 1 mode transport
replay-window 32
mark 1/0x1
aead rfc4106(gcm(aes)) 0xe57364586ae7d5199b8cdf0c11e90dfcefdb76ae 96
sel src 1.1.1.12/32 dst 1.1.1.11/32 proto gre
root at ubuntu:~# ip xfrm policy
src 1.1.1.12/32 dst 1.1.1.11/32 proto tcp dport 7471
dir in priority 5888
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 3 mode transport
src 1.1.1.11/32 dst 1.1.1.12/32 proto tcp sport 7471
dir out priority 5888
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 3 mode transport
src 1.1.1.12/32 dst 1.1.1.11/32 proto tcp sport 7471
dir in priority 5888
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 2 mode transport
src 1.1.1.11/32 dst 1.1.1.12/32 proto tcp dport 7471
dir out priority 5888
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 2 mode transport
src 1.1.1.12/32 dst 1.1.1.11/32 proto gre <---- The old IPsec polcies are
still here
dir in priority 2818
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 1.1.1.11/32 dst 1.1.1.12/32 proto gre
dir out priority 2818
mark 1/0x1
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 1 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0



Thanks,
Ansis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150216/9a6b1d55/attachment-0001.html>


More information about the Users mailing list