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 ([email protected]
<mailto:[email protected]>) 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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
