[Swan] Alcatel IP-Phone VPN IPSEC disconnect after 1 hour
paul at nohats.ca
Fri Nov 13 13:52:55 UTC 2020
> On Nov 13, 2020, at 04:02, Paul Overton <Paul at trustedcyber.co.uk> wrote:
> I found that the Alcatel phones don't work well with DPD.
> I have several Alcatel phones working successfully with Libreswan. Since disabling DPD uptimes have been good.
Glad to hear but dpd does not seem to be the cause of 1h failures ?
> -----Original Message-----
> From: Swan <swan-bounces at lists.libreswan.org> On Behalf Of Hans-Jürgen Brand
> Sent: 13 November 2020 07:39
> To: swan at lists.libreswan.org
> Subject: [Swan] Alcatel IP-Phone VPN IPSEC disconnect after 1 hour
> I’m testing a VPN dialin connection from a Alcatel IP-Phone to Libreswan. The connection gets up and running, but after 1 hour the connection gets broken und the IP-Phone restarts, established a new connection and then I have another hour.
> If tried IKEV1+PSK+XAuth and IKV2+PSK. It does not matter.
You have :
The salifetime cannot be more than 1 day so likely this falls back to the 8h default.
> For me it looks like if the timer ‘EVENT_SA_REPLACE in 3655s’ expired, then I got this problem.
> ⇒ 000 #1: "xauth-psk" 22.214.171.124:62020 STATE_MODE_CFG_R1 (ModeCfg Set sent, expecting Ack); EVENT_SA_REPLACE in 3655s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle;
That would be specific to IKEv1 XAUTH. We know of an issue that if there is packet loss, a retransmit might not always happen. This will be fixed in 4.2.
But if IKEv2 also fails that is not your issue. Can you show logs of the IKEv2 failure ?
> If I use the IP-Phone with Fortigate or Zyxel then it is working.
> Here my System:
> - Ubuntu 20.04.1 LTS
> - Linux Libreswan 3.32 (netkey) on 5.4.0-53-generic
> AAA.BBB.CCC.DDD external public IP of Libreswan
> EEE.FFF.GGG.HHH external public IP of the client (IPPhone)
> cat /etc/ipsec.conf
> version 2.0
> config setup
> conn shared
Please try dpdaction=restart
> 000 State Information: DDoS cookies not required, Accepting new IKE connections
> 000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
> 000 IPsec SAs: total(1), authenticated(1), anonymous(0)
> 000 #1: "xauth-psk" EEE.FFF.GGG.HHH:62020 STATE_MODE_CFG_R1 (ModeCfg Set sent, expecting Ack); EVENT_SA_REPLACE in 3655s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle;
> 000 #2: "xauth-psk" EEE.FFF.GGG.HHH:62020 STATE_QUICK_R1 (sent QR1, inbound IPsec SA installed, expecting QI2); EVENT_RETRANSMIT in 0s; isakmp#1; idle;
> 000 #2: "xauth-psk" EEE.FFF.GGG.HHH mailto:esp.c3af1065 at EEE.FFF.GGG.HHH mailto:esp.82e2afef at 192.168.99.142 mailto:tun.0 at EEE.FFF.GGG.HHH mailto:tun.0 at 192.168.99.142 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B username=vpn522
It looks like it almost restarted but waiting on the last confirmation packet of the remote endpoint. Maybe they are unhappy ? Can you see logs from that end ?
You could try tweaking pfs=yes|no ? That sometimes leads to rekey failures
More information about the Swan