pfSense

When there is an IPv4 address pool configured for mobile IPSec clients, strongswan.conf is generated with the setting "subnet = <the subnet of the v4 pool>" in the configuration section for the attr plugin. When using an IKEv2 VPN for mobile clients, this results in a configuration payload with the type INTERNAL_IP4_SUBNET being sent with the value of the v4 pool subnet. The purpose of INTERNAL_IP4_SUBNET is to specify subnets that should go over the tunnel. It's described here:

https://tools.ietf.org/html/rfc5996#section-3.15.2

Two approaches are mentioned there. Either INTERNAL_IP4_SUBNET contains additional networks to those in the phase 2 traffic selectors or INTERNAL_IP4_SUBNET contains the subnets that are covered by the phase 2 traffic selectors that should be sent through the remote gateway. The first case is like a union of the traffic selectors with INTERNAL_IP4_SUBNET and the second case is like an intersection of the two. When using IKEv2 with iOS 9 or OS X El Capitan, the latter approach is used. Consequently, the only traffic that ends up being sent over an IPsec tunnel established with IKEv2 on iOS9 is traffic bound for the v4 pool subnet. The "VPN" icon shows in the upper corner of the screen indicating you are connected to a VPN yet none of your traffic actually gets sent over the tunnel unless you happen to try to access something within the pool subnet.

The config generation routine should be changed so that if the "Provide a list of accessible networks to clients" box is checked, the charon.plugins.attr.subnet attribute is set to the list of phase 2 subnets. Otherwise it should not be set.

This needs to be tested against a variety of clients.