Project

General

Profile

Issue #3314

VPN connection dropped after overnight

Added by Tom Hsiung about 1 month ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.6.2
Resolution:
No change required

Description

I did not find any useful information from the system log.

The roadwarrior connection just broke overnight, on my iPhone.

On my Mac, the connection could last more than 10 hours, while I keep my Mac from sleeping.

Below is the ipsec.conf file.

conn roadwarrior
        auto=add
        reauth=no
        rekey=yes
        compress=no
        type=tunnel
        fragmentation=yes
        forceencaps=yes
        dpdaction=none
        dpddelay=3600s
        ike=<chiper>
        esp=<chiper>
        keyingtries=0
        ikelifetime=3h
        lifetime=24h
        leftsendcert=always
        left=leftdomain
        leftauth=pubkey
        leftcert=leftcertfile
        leftid=@leftdomain
        leftsubnet=0.0.0.0/0
        right=%any
        rightauth=eap-tls
        eap_identity=%identity
        rightcert=rightcertfile
        rightsourceip=x.x.x.x/x
        rightid=@rightdomain

History

#1 Updated by Tom Hsiung about 1 month ago

It seem that the rekeying has some problem.

ikelifetime=1m
lifetime=2m

Tested with this time interval and the VPN connection closed right at 2 minutes.

Just want to the VPN connection on my devices keeps on until I turn it off manually.

Check logs,

unable to reestablish IKE_SA due to asymmetric setup

Tom

#2 Updated by Tom Hsiung about 1 month ago

It looks like that,

unique ids=never

So the Mac and iPhone use a same connection. When I slept last night, the Mac went into sleep state. Later when it was the time for IKE rekeying, the strongSwan server failed to do so because the Mac was in sleep. So the strongSwan sever simply dropped that connection. At the same time, the iPhone used the same connection, so when the Child SA was dropped due to Mac, the iPhone also got dropped. This is my explanation for this phenomenon.

Tom

#3 Updated by Noel Kuntze about 1 month ago

  • Category set to configuration
  • Status changed from New to Feedback

Don't reuse IDs on different clients.
And also follow the HelpRequests page, please. It's not a joke or something.

#4 Updated by Tom Hsiung about 1 month ago

Noel Kuntze wrote:

Don't reuse IDs on different clients.
And also follow the HelpRequests page, please. It's not a joke or something.

Thank you for your respond, sir. But I use roadwarrior mode. Some more than one clients need to connect to the strongSwan server. Could you show me how to realize this purpose while keep the uniqueids=yes?

#5 Updated by Noel Kuntze about 1 month ago

It doesn't matter what "mode" you use. I am talking about the leftid/rightid/id values, not the subnets. IDs uniquely identify clients, so if you reuse one for different clients, strongSwan will act as if they were the same. It's not possible to always distinguish clients without such a concept (without using IDs). Your problem reads a lot like you reuse IDs (if you use certitifcate authentication, then possibly also certificates). Make sure you don't do that.

#6 Updated by Tom Hsiung about 1 month ago

I made some testing today and after checking the log more deeply, I found the direct reasons for the disconnection was due to the failure of scheduled rekeying.

There is logs showing retransmit events and giving up after 5 times. I think it is caused by a router between my strongSwan server and clients. The router's SNAT function could not be turned off. So after some significant of time without traffic (overnight), the router forgot the SNAT record for these clients behind the router. Later, when the strongSwan server tried to rekey, these rekey request packets were not able to reach clients as there was no NAT records for that.

PS: forceencaps=yes

So in the macOS server app, there is a function called "Enable NAT keepalive while the device is asleep". This option keeps the SNAT records remaining there. So that future rekeying request could get in.

Tom

#7 Updated by Noel Kuntze about 1 month ago

  • Status changed from Feedback to Closed
  • Resolution set to No change required

If forceencaps=yes changed the behaviour then the router fiddled with the NAT detection payloads (they just contain the IP addresses of the participants).
""Enable NAT keepalive while the device is asleep"" makes sense.
Glad this could be resolved.

#8 Updated by Tom Hsiung about 1 month ago

Strange, even with the iOS's NAT keepalive turned on, I still get retransmit errors.

charon: 06[IKE] retransmit 5 of request with message ID 0

And later,

charon: 10[IKE] giving up after 5 retransmits
charon: 10[CFG] lease x.x.x.1 by 'client' went offline

#9 Updated by Tom Hsiung about 1 month ago

Can I use the iOS's DPD (once every a minute) to maintain NAT mapping?

Tom

#10 Updated by Noel Kuntze about 1 month ago

Strange, even with the iOS's NAT keepalive turned on, I still get retransmit errors.

They're not errors. They're just retransmissions because the other peer did not acknowledge the receipt.

Can I use the iOS's DPD (once every a minute) to maintain NAT mapping?

Yes, DPD works for maintaing NAT mappings.

Also available in: Atom PDF