VPN connection dropped after overnight
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
#1 Updated by Tom Hsiung about 1 month ago
It seem that the rekeying has some problem.
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.
unable to reestablish IKE_SA due to asymmetric setup
#2 Updated by Tom Hsiung about 1 month ago
It looks like that,
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.
#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
#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.
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.
#7 Updated by Noel Kuntze about 1 month ago
- Status changed from Feedback to Closed
- Resolution set to No change required
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.
#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.