I tell a slight lie. The tunnel eventually came back up in 12.5 min,
but next time I tested it, after 1h20 it did not come back up until
I tried to pass traffic from the remote end to local.
On 02/05/2019 14:13, Nick Howitt wrote:
I have an IKEv2 conn with one end behind NAT:
Nat'd (remote):
conn nick-ikev2
type=tunnel
authby=secret
auto=start
left=10.20.40.248
leftsourceip=192.168.20.1
leftsubnet=192.168.20.0/24
leftid=@clearos_in_clearvm
right=my.fqdn
rightsubnet=172.17.2.0/24
rightid=@nick
ikev2=insist
dpdaction=restart
dpdtimeout=120
dpddelay=30
Other (local) end:
conn nick-ikev2
type=tunnel
authby=secret
auto=add
left=%any
#left=209.90.117.194
leftsubnet=192.168.20.0/24
leftid=@clearos_in_clearvm
right=%defaultroute
rightsubnet=172.17.2.0/24
rightsourceip=172.17.2.1
rightid=@nick
ikev2=insist
dpdaction=restart
dpdtimeout=120
dpddelay=30
rekey=no
salifetime=9h
ikelifetime=2h
The tunnel comes up fine. If I then reload the conn at the local
end, the tunnel does not automatically reconnect until I do an
"ipsec auto --start nick-ikev2" at the remote end. Shouldn't the
tunnel be automatically reconnecting within 2 1/2 minutes (delay +
timeout)? Note it does not matter if left=%any or
left=209.90.117.194 - the results are the same.
Using tcpdump at the remote end:
tcpdump -nn -i eth0 'host 90.255.224.113 and (port 500 or port
4500)'
This shows nothing at all, as if no DPD packets are being sent.
Obviously a similar tcpdump at the other end shows nothing being
received.
Using libreswan-3.25-4.1.el7_6.x86_64.
Regards,
Nick
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
|
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
