Project

General

Profile

Feature #2185

INTERNAL_IP4_SUBNET Attribute Support in Android Client

Added by Euphrates Greene about 4 years ago. Updated about 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
android
Target version:
-
Start date:
08.12.2016
Due date:
Estimated time:
Resolution:

Description

Currently, the Android Strongswan client ignores the INTERNAL_IP4_SUBNET attribute in favor of the traffic selector. In the case of VPN setups on Cisco routers (and likely other VPN headends) this attribute is used for providing split tunnel parameters to the client. Otherwise, the client will propose full tunnel TS and the VPN headend will agree. Could there be a way to have the client overwrite the traffic selector if the INTERNAL_IP4_SUBNET attribute is provided or a customized setting, similar to the default Android client that allows you to manually specify the traffic selector(s) you want to use so the VPN headend can agree to them. This would be helpful for gateways that do not support traffic selector narrowing with dynamic VPNs.

See the following resources:

https://wiki.strongswan.org/issues/191

https://wiki.strongswan.org/issues/737

https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling


Related issues

Related to Feature #191: INTERNAL_IP4_NETMASK and INTERNAL_IP4_SUBNET support stateClosed25.04.2012

History

#1 Updated by Tobias Brunner about 4 years ago

  • Status changed from New to Feedback

Otherwise, the client will propose full tunnel TS and the VPN headend will agree.

Are you sure? Since the attributes are exchanged only after the client already proposed the traffic selectors for the initial CHILD_SA it would have to terminate that and establish a new CHILD_SA with the proposed subnets using a CREATE_CHILD_SA exchange. Unless it initiated the IKE_SA without an initial CHILD_SA, using the extension defined in RFC 6023, which is currently not supported by strongSwan.

Another option is that the client simply interprets the supplied subnets as narrowing instructions in regards to its locally installed remote traffic selector (or installs the routes accordingly for route based implementations) and the negotiated TSr stays at 0.0.0.0/0.

Could there be a way to have the client overwrite the traffic selector if the INTERNAL_IP4_SUBNET attribute is provided or a customized setting, similar to the default Android client that allows you to manually specify the traffic selector(s) you want to use so the VPN headend can agree to them.

Both are possible I guess. A limited handling of INTERNAL_IP4_SUBNET (i.e. derive routes from them if they are contained in TSr or narrow TSr locally) would be relatively easy to implement. Making TSr (or the routes) configurable is also possible but might be more work (GUI, data storage etc.).

This would be helpful for gateways that do not support traffic selector narrowing with dynamic VPNs.

Which, of course, is a huge limitation on their part as that's one of the major useful new features of IKEv2 (and wouldn't they have to support it anyway if the client proposes a more narrow TSr in the first place?).

#2 Updated by Euphrates Greene about 4 years ago

Are you sure? Since the attributes are exchanged only after the client already proposed the traffic selectors for the initial CHILD_SA it would have to terminate that and establish a new CHILD_SA with the proposed subnets using a CREATE_CHILD_SA exchange. Unless it initiated the IKE_SA without an initial CHILD_SA, using the extension defined in RFC 6023, which is currently not supported by strongSwan.

Another option is that the client simply interprets the supplied subnets as narrowing instructions in regards to its locally installed remote traffic selector (or installs the routes accordingly for route based implementations) and the negotiated TSr stays at 0.0.0.0/0.

See the following:

https://www.cisco.com/c/en/us/td/docs/ios/sec_secure_connectivity/configuration/guide/15_0/sec_secure_connectivity_15_0_book/sec_ipsec_virt_tunnl.html#wp1083582%0A

Specifically:

IPsec SA Traffic Selectors

Static VTIs (SVTIs) support only a single IPsec SA that is attached to the VTI interface. The traffic selector for the IPsec SA is always "IP any any."

A dynamic VTI (DVTIs) also is a point-point interface that supports only a single IPsec SA, but the DVTI is flexible in that it can accept the IPsec selectors that are proposed by the initiator.

This type of configuration allows the initiator to propose the traffic selector and the gateway accepts. I'm using the dynamic VTI (DVTI).

Which, of course, is a huge limitation on their part as that's one of the major useful new features of IKEv2 (and wouldn't they have to support it anyway if the client proposes a more narrow TSr in the first place?).

See the following:

https://www.cisco.com/image/gif/paws/116008/116008-flexvpn-nge-config-00.pdf

The use of Dynamic Virtual Tunnel Interface (DVTI) on the FlexVPN router allows this device to respond to the presented Traffic Selector with a mirror of the Traffic Selector that was presented.

It seems, based on this, it will submit an IP any any as the traffic selector but, when the initiator narrows it, the gateway will mirror it on its side. I have a support case regarding narrowing the traffic selectors when using DVTI for IKEv2 configuration since I've been unable to find any meaningful configurations on the Internet.

#3 Updated by Tobias Brunner almost 4 years ago

  • Related to Feature #191: INTERNAL_IP4_NETMASK and INTERNAL_IP4_SUBNET support state added

Also available in: Atom PDF