[Swan] Routes dropping

Nick Howitt nick at howitts.co.uk
Thu Jun 22 18:05:17 UTC 2017


Hi All,

I've just noticed something similar. I have a conn with auto=add and 
rekey=no:

conn PaulIn
  type=tunnel
  authby=secret
  dpdtimeout=120
  dpddelay=30
  auto=add
  left=%defaultroute
  leftsourceip=172.17.2.1
  leftsubnet=172.17.2.0/24
  leftid=@Nick
  right=%any
  rightsubnet=192.168.30.0/24
  salifetime=24h
  dpdaction=clear
  ikelifetime=24h
  ike=aes256-sha1;modp2048
  phase2alg=aes256-sha1
  rekey=no

So here is a section of logs:

Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #67: the 
peer proposed: 172.17.2.0/24:0/0 -> 192.168.30.0/24:0/0
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
responding to Quick Mode proposal {msgid:8cb302a2}
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75:     
us: 172.17.2.0/24===82.19.158.192[@Nick]
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: them: 
92.25.208.84===192.168.30.0/24
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
keeping refhim=0 during rekey
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jun 16 23:05:55 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 
tunnel mode {ESP=>0x7866618c <0x27d0e916 xfrm=AES_256-HMAC_SHA1 
NATOA=none NATD=none DPD=active}
Jun 16 23:05:56 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jun 16 23:05:56 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x7866618c 
<0x27d0e916 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=active}
Jun 16 23:15:53 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #74: 
deleting state (STATE_QUICK_R2)
Jun 16 23:15:53 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #74: ESP 
traffic information: in=0B out=0B
Jun 16 23:45:20 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #67: 
received Delete SA payload: self-deleting ISAKMP State #67
Jun 16 23:45:20 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #67: 
deleting state (STATE_MAIN_R3)
Jun 16 23:45:20 server pluto[27537]: packet from 92.25.208.84:500: 
received and ignored empty informational notification payload
Jun 16 23:45:28 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: DPD: 
could not find newest phase 1 state - initiating a new one
Jun 16 23:45:28 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #76: 
initiating Main Mode
Jun 16 23:45:28 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
deleting state (STATE_QUICK_R2)
Jun 16 23:45:28 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: ESP 
traffic information: in=0B out=0B
Jun 16 23:45:28 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #75: 
down-client output: /usr/libexec/ipsec/_updown.netkey: delsource "ip 
addr del 172.17.2.1/24 dev enp2s0" failed (RTNETLINK answers: Cannot 
assign requested address)
Jun 16 23:46:32 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #76: max 
number of retransmissions (8) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKEv1 message
Jun 16 23:46:32 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #76: 
starting keying attempt 2 of an unlimited number
Jun 16 23:46:32 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #77: 
initiating Main Mode to replace #76
Jun 16 23:46:32 server pluto[27537]: deleting other state #76 
(STATE_MAIN_I1) "PaulIn"[2] 92.25.208.84
Jun 16 23:47:36 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #77: max 
number of retransmissions (8) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKEv1 message
Jun 16 23:47:36 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #77: 
starting keying attempt 3 of an unlimited number
Jun 16 23:47:36 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #78: 
initiating Main Mode to replace #77
Jun 16 23:47:36 server pluto[27537]: deleting other state #77 
(STATE_MAIN_I1) "PaulIn"[2] 92.25.208.84
Jun 16 23:48:40 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #78: max 
number of retransmissions (8) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKEv1 message
Jun 16 23:48:40 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #78: 
starting keying attempt 4 of an unlimited number
Jun 16 23:48:40 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #79: 
initiating Main Mode to replace #78
Jun 16 23:48:40 server pluto[27537]: deleting other state #78 
(STATE_MAIN_I1) "PaulIn"[2] 92.25.208.84
Jun 16 23:49:44 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #79: max 
number of retransmissions (8) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKEv1 message
Jun 16 23:49:44 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #79: 
starting keying attempt 5 of an unlimited number
Jun 16 23:49:44 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #80: 
initiating Main Mode to replace #79
Jun 16 23:49:44 server pluto[27537]: deleting other state #79 
(STATE_MAIN_I1) "PaulIn"[2] 92.25.208.84
Jun 16 23:50:48 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #80: max 
number of retransmissions (8) reached STATE_MAIN_I1.  No response (or no 
acceptable response) to our first IKEv1 message
Jun 16 23:50:48 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #80: 
starting keying attempt 6 of an unlimited number
Jun 16 23:50:48 server pluto[27537]: "PaulIn"[2] 92.25.208.84 #81: 
initiating Main Mode to replace #80
Jun 16 23:50:48 server pluto[27537]: deleting other state #80 
(STATE_MAIN_I1) "PaulIn"[2] 92.25.208.84

I looks like it has got its knickers in a twist and having either lost 
or deleted the conn, it is attempting to initiate one and retries every 
four seconds. I don't think it should ever do this with auto=add and 
rekey=no. Looking at the subsequent logs it looks like the remote end 
changed IP address (it is an ADSL connection) which kicked this all off, 
but libreswan continued to use the old address - not that it should be 
rekeying. This is with libreswan-3.20-1.el7.x86_64. Only restarting 
ipsec fixes it.

Regards,

Nick

On 20/06/2017 14:03, Bob Cribbs wrote:
> Sure, what log files do you think are relevant?
>
> There doesnt seem to be anything in the `/var/log/auth.log` around the 
> time the routes disappear, there is nothing in `/var/log/messages.log` 
> file either.
>
> Or should i change pluto's log level to `all`?
>
> On 20 June 2017 at 16:00:02, Paul Wouters (paul at nohats.ca 
> <mailto:paul at nohats.ca>) wrote:
>
>> Can you arrange for some logfiles I can have a look at?
>>
>> Can you also try a 3.20rcX release candidate?
>>
>> Sent from my iPhone
>>
>> On Jun 20, 2017, at 08:27, Bob Cribbs <bob.cribbs at policystat.com 
>> <mailto:bob.cribbs at policystat.com>> wrote:
>>
>>> Hi,
>>>
>>> Im experiencing a new problem with my upgrade process (3.12->3.20), 
>>> this time it's the routes.
>>>
>>> I have ~70 tunnels setup on my server.
>>> After ipsec is (re)started, all the routes come up.
>>> But then 1-2 minutes later, there are only a subset of those that 
>>> are still up, ~10 of them. It's always the same 10 that are persisting.
>>> All the tunnels are still showing up as connected, including those 
>>> that are now missing the routes.
>>>
>>> Sending data through the tunnel, only works for those that have 
>>> routes, for the other ones is timing out.
>>>
>>> I tried downgrading from 3.20 -> 3.19 same problem.
>>> I tried downgrading further 3.19 -> 3.18. Routes seem to be 
>>> persisting on 3.18.
>>>
>>> I suspect there is a problem with encapsulation and NAT and keepalive.
>>> On 3.12 and 3.18, i used `forceencaps=yes`
>>> On 3.20 i tried `encapsulation=yes`, and `encapsulation=auto` routes 
>>> are disconnecting with either of them.
>>> ```
>>> conn customer
>>>         authby=secret
>>>         dpddelay=40
>>>         dpdtimeout=120
>>>         dpdaction=restart
>>>         auto=start
>>>         encapsulation=yes
>>>         pfs=yes
>>>         ike=aes256-sha1
>>>         phase2alg=aes256-sha1
>>>         left=%defaultroute
>>>         leftid=184.X.X.X
>>>         leftsourceip=184.X.X.X
>>>         leftsubnet=184.X.X.X/32
>>>         right=72.Y.Y.Y
>>>         rightid=72.Y.Y.Y
>>>         rightsubnet=10.B.B.B/32
>>> ```
>>> Once the route disappears, it doesnt come back even if i try:
>>> ```
>>> $ sudo ipsec auto --down customer
>>> $ sudo ipsec auto --up customer
>>> ```
>>>
>>> Am I missing some config to keep the route up on the 3.20 version?
>>>
>>> Thank you.
>>> _______________________________________________
>>> Swan mailing list
>>> Swan at lists.libreswan.org <mailto:Swan at lists.libreswan.org>
>>> https://lists.libreswan.org/mailman/listinfo/swan
>
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan



More information about the Swan mailing list