Project

General

Profile

Issue #3166

Windows 10 tears down tunnel after 5 minutes

Added by János Tálas 16 days ago. Updated 9 days ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.7.1
Resolution:
No change required

Description

Hi strongSwan Team,

I'm trying to use my home computer remotely while I'm on the go. I set up a strongSwan VPN server and I can successfully connect to it from the aforementioned desktop as well as from my MacBook. After connected both of them I can RDP to the desktop. You are awesome.

However, after exactly 5 minutes of idle the Windows machine tore down the tunnel. The connection is still ESTABLISHED (since 3 days, rekeying regularly), but there was no INSTALLED TUNNEL anymore. I see from this FAQ that this is intentional: [[https://docs.microsoft.com/en-gb/azure/vpn-gateway/vpn-gateway-vpn-faq]] (Q "Why does my policy-based VPN tunnel go down when traffic is idle?"). I couldn't find any way to change this, not even a hint of that being possible.

My questions are
  • do you happen to have any knowledge if this tunnel tear down can be stopped or this 5 minute timeout increased at least?
  • can a tunnel be built by the strongSwan side or can strongSwan somehow force the client to rebuild?
  • is what I am trying to do completely impossible?

ipsec.conf

config setup
    uniqueids=never # allow multiple connections per user
    charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2" 

conn %default
    fragmentation=yes
    rekey=no
    dpdaction=clear
    keyexchange=ikev2
    compress=yes
    dpddelay=35s
    lifetime=3h
    ikelifetime=12h

    ike=aes256gcm16-prfsha512-ecp384,aes256-sha2_512-prfsha512-ecp384,aes256-sha2_384-prfsha384-ecp384!
    esp=aes256gcm16-ecp384,aes256-sha2_512-prfsha512-ecp384!

    left=%any
    leftauth=pubkey
    leftid=1.2.3.4
    leftcert=1.2.3.4.crt
    leftsendcert=always
    leftsubnet=198.26.19.0/24,fd9d:bc11:4020::/48

    right=%any
    rightauth=pubkey
    rightsourceip=198.26.19.0/24,fd9d:bc11:4020::/48
    rightdns=1.2.3.4

conn ikev2-pubkey
    auto=add

ipsec statusall (shorty after connected)

Status of IKE charon daemon (strongSwan 5.7.1, Linux 5.0.0-25-generic, x86_64):
  uptime: 4 days, since Aug 29 16:19:18 2019
  malloc: sbrk 2703360, mmap 0, used 1514672, free 1188688
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aes sha2 random nonce x509 revocation pubkey pkcs7 pkcs8 pkcs12 pgp pem openssl hmac gcm kernel-netlink socket-default stroke
Virtual IP pools (size/online/offline):
  198.26.19.0/24: 254/2/5
  fd9d:bc11:4020::/48: 2147483646/2/5
Listening IP addresses:
  1.2.3.4
  ...
Connections:
ikev2-pubkey:  %any...%any  IKEv2, dpddelay=35s
ikev2-pubkey:   local:  [1.2.3.4] uses public key authentication
ikev2-pubkey:    cert:  "CN=1.2.3.4" 
ikev2-pubkey:   remote: uses public key authentication
ikev2-pubkey:   child:  198.26.19.0/24 fd9d:bc11:4020::/48 === dynamic TUNNEL, dpdaction=clear
Security Associations (2 up, 0 connecting):
ikev2-pubkey[64]: ESTABLISHED 2 minutes ago, 1.2.3.4[1.2.3.4]...5.204.65.17[CN=windows_vm]
ikev2-pubkey[64]: IKEv2 SPIs: ae8110c284939517_i 377400f593c3dde6_r*, rekeying disabled
ikev2-pubkey[64]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
ikev2-pubkey{43}:  INSTALLED, TUNNEL, reqid 42, ESP in UDP SPIs: c045dc51_i 4863cf16_o
ikev2-pubkey{43}:  AES_GCM_16_256, 0 bytes_i, 0 bytes_o, rekeying disabled
ikev2-pubkey{43}:   198.26.19.0/24 fd9d:bc11:4020::/48 === 198.26.19.7/32 fd9d:bc11:4020::7/128

ipsec statusall (after 5 minutes idle)

Status of IKE charon daemon (strongSwan 5.7.1, Linux 5.0.0-25-generic, x86_64):
  uptime: 4 days, since Aug 29 16:19:18 2019
  malloc: sbrk 2703360, mmap 0, used 1503008, free 1200352
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon aes sha2 random nonce x509 revocation pubkey pkcs7 pkcs8 pkcs12 pgp pem openssl hmac gcm kernel-netlink socket-default stroke
Virtual IP pools (size/online/offline):
  198.26.19.0/24: 254/2/5
  fd9d:bc11:4020::/48: 2147483646/2/5
Listening IP addresses:
  1.2.3.4
  ...
Connections:
ikev2-pubkey:  %any...%any  IKEv2, dpddelay=35s
ikev2-pubkey:   local:  [1.2.3.4] uses public key authentication
ikev2-pubkey:    cert:  "CN=1.2.3.4" 
ikev2-pubkey:   remote: uses public key authentication
ikev2-pubkey:   child:  198.26.19.0/24 fd9d:bc11:4020::/48 === dynamic TUNNEL, dpdaction=clear
Security Associations (2 up, 0 connecting):
ikev2-pubkey[64]: ESTABLISHED 5 minutes ago, 1.2.3.4[1.2.3.4]...5.204.65.17[CN=windows_vm]
ikev2-pubkey[64]: IKEv2 SPIs: ae8110c284939517_i 377400f593c3dde6_r*, rekeying disabled
ikev2-pubkey[64]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384

History

#1 Updated by Tobias Brunner 16 days ago

  • Category changed from windows to interoperability
  • Status changed from New to Feedback

However, after exactly 5 minutes of idle the Windows machine tore down the tunnel. The connection is still ESTABLISHED (since 3 days, rekeying regularly), but there was no INSTALLED TUNNEL anymore. I see from this FAQ that this is intentional.

Which client do you use on Windows? The Agile VPN client? Or the one built into the advanced firewall? (The latter seems to correspond more to policy-based VPNs, not sure if the FAQ entry even applies to any of them or if that is some other functionality supported by Windows server.)

  • do you happen to have any knowledge if this tunnel tear down can be stopped or this 5 minute timeout increased at least?

I don't.

  • can a tunnel be built by the strongSwan side or can strongSwan somehow force the client to rebuild?

As documented, the Agile VPN client has some issues if the server initiates rekeyings. Not sure if it also has an idle timeout or how it would react if the server then initiated a new CHILD_SA.

  • is what I am trying to do completely impossible?

Maybe. The simplest workaround is probably to constantly produce traffic somehow.

#2 Updated by János Tálas 16 days ago

Thank you for your extremely quick answer, it is much appreciated!

Tobias Brunner wrote:

Which client do you use on Windows? The Agile VPN client? Or the one built into the advanced firewall? (The latter seems to correspond more to policy-based VPNs, not sure if the FAQ entry even applies to any of them or if that is some other functionality supported by Windows server.)

Well, I don't have any special client software installed, I created the VPN using the Add-VpnConnection CmdLet with Machine Certificate authentication. I guess it is the Agile VPN client?

As documented, the Agile VPN client has some issues if the server initiates rekeyings.

Please forgive me if I'm using the wrong terminology here, but I see successful rekeying in the logs. You mean that a server initiated rekey would be a way to rebuild the tunnel? As I mentioned, the connection stays ESTABLISHED between the rekeyings.

...
Sep  3 09:59:57 creativiumnetwork charon: 15[IKE] IKE_SA ikev2-pubkey[66] state change: CONNECTING => ESTABLISHED
Sep  3 09:59:57 creativiumnetwork charon: 15[IKE] IKE_SA ikev2-pubkey[66] rekeyed between 1.2.3.4[1.2.3.4]...5.204.65.17[CN=windows_vm]
Sep  3 09:59:57 creativiumnetwork charon: 15[MGR] checkin IKE_SA ikev2-pubkey[66]
Sep  3 09:59:57 creativiumnetwork charon: 15[MGR] checkin of IKE_SA successful
...

Maybe. The simplest workaround is probably to constantly produce traffic somehow.

Yeah, I'm thinking about spinning up a VM just to have another client on the VPN that the desktop can ping.
By the way (really noob question coming up): There is no gateway IP on the VPN connection. Should my VPN server have a virtual IP and be pingable within the virtual network I could solve this with a simple, continuous ping. Can the server have an IP in the virtual address? Actually, I tried to keep the connection up by pinging the VPN servers public IP but that just didn't work apparently.

#3 Updated by Tobias Brunner 16 days ago

I guess it is the Agile VPN client?

Yep.

Please forgive me if I'm using the wrong terminology here, but I see successful rekeying in the logs. You mean that a server initiated rekey would be a way to rebuild the tunnel? As I mentioned, the connection stays ESTABLISHED between the rekeyings.

That's only the IKE_SA (control connection), there is no CHILD_SA (to transport actual traffic) once the client terminates it. It's up to the client to initiate another CHLID_SA once it notices traffic to the remote subnets.

Maybe. The simplest workaround is probably to constantly produce traffic somehow.

Yeah, I'm thinking about spinning up a VM just to have another client on the VPN that the desktop can ping.

That's overkill. You can just assign an additional IP to the server (on any of its interfaces, even lo) if it's necessary.

By the way (really noob question coming up): There is no gateway IP on the VPN connection. Should my VPN server have a virtual IP and be pingable within the virtual network I could solve this with a simple, continuous ping.

What do you mean? There is no actual IP in 198.26.19.0/24 or fd9d:bc11:4020::/48 on the server side? That renders the VPN pretty much useless (unless the goal is to communicate to other VPN clients in these subnets). You might also want to read ForwardingAndSplitTunneling.

Can the server have an IP in the virtual address? Actually, I tried to keep the connection up by pinging the VPN servers public IP but that just didn't work apparently.

No, traffic to the public IP won't go via VPN, only traffic matching the negotiated traffic selectors (the subnets mentioned above and seen in the status output) will. So assigning an IP from these subnets to the server will be necessary to send data via VPN (just make sure you exclude these IPs from the virtual IP pools e.g. by setting a start address != 0 in rightsourceip).

#4 Updated by János Tálas 9 days ago

Thank you for your help!

I did what you suggested and added X.X.X.1 as a local IP and started pinging it in every 4 minutes and that keeps windows from tearing down the tunnel.

I appreciate your help, especially since the problem was not at all a strongSwan issue.

You may close this ticket at your convenience.

#5 Updated by Tobias Brunner 9 days ago

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

Also available in: Atom PDF