Project

General

Profile

Issue #1037

IOS 9 Apple IKEv2 DPD problem with strongswan IKEv2 5.3.2

Added by Philippe Racette over 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.3.2
Resolution:
Fixed

Description

Hello,

I have been trying to test the new IKEv2 protocol fixes done in IOS 9 Beta 2.

I have been having an issue with the following setup :

Apple IPad --- Fw/Nat --- Internet --- Fw/NAT --- VPN Strongswan Gw

Basically, we go through two NAT firewalls to access the VPN gateway.

The connection works for both IKA SA_INIT and IKE AUTH but the DPD sent by the Strongswan Gateway are ignored by the Ipad or dropped. (no logs seen on the device)

My question is :

- Is this configuration possible with strongswan i.e. Do i have to expose the VPN gateway with a public IP on the network edge ?

My configuration (ipsec.conf):

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev2
    mobike=yes
    ike=aes256-sha256-modp1024,aes256-sha256
    esp=aes256-sha256-modp1024,aes256-sha256

# Ikev2, Pre-Shared Key, AES256-SHA256-MODP1024(DH group 2)
conn road_ikev2_psk
     authby=secret
     rekey=yes
     dpdaction=clear
     left=%any
     leftsubnet=0.0.0.0/0
     leftsourceip=%cfg
     leftid=server@sample.org
     right=%any
     rightid=*@sample.org
     rightsourceip=10.50.50.10-10.50.50.20
     rightdns=XXX.XXX.XXX.XXX
     auto=add

Related issues

Related to Bug #2126: iOS 10 does not respond to DPDs because strongSwan responder (behind a NAT) adds NAT-D notifiesClosed29.09.2016

History

#1 Updated by Tobias Brunner over 6 years ago

  • Description updated (diff)
  • Status changed from New to Feedback

- Is this configuration possible with strongswan i.e. Do i have to expose the VPN gateway with a public IP on the network edge ?

No, this is absolutely possible. You should rather ask whether iOS is capable of this, as it is the new implementation on the block :)

And DPDs in IKEv2 are just empty INFORMATIONAL exchanges, so the client can not really ignore these (or not support/disable DPD for that matter), at least not if it is RFC compliant. Is there any way to see if the DPDs reach the client network? You can also try initiating a rekeying of the CHILD_SA from the server by using the ipsec stroke rekey <name with optional suffix as for other commands> command, to check if the client responds to CREATE_CHILD_SA messages.

#2 Updated by Philippe Racette over 6 years ago

The DPD reach the device indeed, i can see them using an rvi interface on my Mac.

When i remove the NAT in front the gateway and use the ip address directly in the IOS client the DPD are answered by the IPAD.

My guess seems to point that IOS maybe does not implement it. I guess I will have to generate a request with them to see if i can clarify this issue otherwise it is an important omission on their part... it's still in beta after all.

My understanding was that DPD server side was absolutely necessary to avoid dead peers being left opened on the server side... is there another way to achieve the same behavior ?

#3 Updated by Philippe Racette over 6 years ago

One thing i have noticed also is the presence of Notify extensions with NAT source ip and destination ip in the DPD itself.

When i do not have this payload, i.e. NEXTPayload is NONE i get an answer from the Ipad otherwise it does not answer.

My guess is that they ignore the packet. (in a very silent way so far)

#4 Updated by Tobias Brunner over 6 years ago

My understanding was that DPD server side was absolutely necessary to avoid dead peers being left opened on the server side... is there another way to achieve the same behavior ?

If you use uniqueids=yes (or no and the clients send INITIAL_CONTACT notifies) then a previous SA with the same identities will be replaced if a client reconnect. Rekeying exchanges (or any other IKEv2 exchange for that matter) will also work as DPD, i.e. if the clients are not reachable anymore when the server tries to rekey the SAs they will get closed too.

One thing i have noticed also is the presence of Notify extensions with NAT source ip and destination ip in the DPD itself.

Yes, that's part of the MOBIKE extension where these notifies may be added to detect changes in the NAT situation of the peers.

When i do not have this payload, i.e. NEXTPayload is NONE i get an answer from the Ipad otherwise it does not answer.

My guess is that they ignore the packet. (in a very silent way so far)

Interesting, but I guess they added MOBIKE support only recently so there is hope they'll fix it until the final release.

#5 Updated by Philippe Racette over 6 years ago

By the way, i do not know if you ever covered the subject but with Managed (Always On VPN) Iphones, the iphone generates two tunnels to strongswan, one for wifi and one for LTE.

I wondered if this is an issue which would require an article on on your website.

#6 Updated by Tobias Brunner over 6 years ago

By the way, i do not know if you ever covered the subject but with Managed (Always On VPN) Iphones, the iphone generates two tunnels to strongswan, one for wifi and one for LTE.

Hm, they do that for IKEv1 or IKEv2, or both? For IKEv2 that would not make much sense if they implement MOBIKE. Anyway, I guess that would require setting uniqueids=no (or even never, depending on whether INITIAL_CONTACT notifies are sent by the client for the duplicate SA) to make this work.

#7 Updated by Philippe Racette over 6 years ago

Yes they do this for Ikev2 (i.e. most probably ikev1 too). I had been using uniqueids=never but have been encountering drops of tunnel on the cellular network.

I am testing different configurations to solve the issue.

#8 Updated by Roger Skjetlein over 6 years ago

Was there ever a 'fix' for this?

I am seeing the same problem for ios release 9.0.

#9 Updated by Philippe Racette over 6 years ago

Hello Roger,

Well so far DPD message ID problem has been resolved but if you rely on the server side dpd to work then you will encounter an issue.

I rely only the client-side dpd for now (i.e. basically the setting Low-Medium-High which you will configure in ios profile Apple Configurator).

Hope this helps.

#10 Updated by Tobias Brunner about 6 years ago

Well so far DPD message ID problem has been resolved but if you rely on the server side dpd to work then you will encounter an issue.

Which you originally reported in #1040.

I rely only the client-side dpd for now (i.e. basically the setting Low-Medium-High which you will configure in ios profile Apple Configurator).

So the problem with the NAT-D payloads is not fixed yet?

#11 Updated by Philippe Racette about 6 years ago

Everytime I use server side dpd for my connection I get an early drop of tunnel since the server side does not receive back from the Iphone or Ipad.

#12 Updated by Tobias Brunner over 5 years ago

  • Related to Bug #2126: iOS 10 does not respond to DPDs because strongSwan responder (behind a NAT) adds NAT-D notifies added

#13 Updated by Tobias Brunner about 5 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

I think this is resolved by the fix in #2126.

Also available in: Atom PDF