[Swan] Alcatel IP-Phone VPN IPSEC disconnect after 1 hour

[Paul Wouters]

> 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 :

ikelifetime=86400
salifetime=864000

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"[2] 31.16.111.93: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
>  virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!172.20.192.64/26
>  protostack=netkey
>  interfaces=%defaultroute
>  uniqueids=yes
>  plutodebug="tmi"
>  logfile=/var/log/pluto.log
>  listen=192.168.99.142
> 
> conn shared
>  left=%defaultroute
>  leftid=AAA.BBB.CCC.DDD   
>  right=%any
>  authby=secret
>  keyingtries=0
>  dpddelay=3600
>  dpdtimeout=4800
>  dpdaction=hold

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  
> 000 #1: "xauth-psk"[2] 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"[2] 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"[2] 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 

Paul