strongSwan

Nope, strongSwan currently does not support these attributes.

Ouch...
I believe the current approach to split-tunneling is via traffic selectors(TS). Client proposes 0.0.0.0/0 and server tailors this proposal in its response with whatever specified in leftsubnets. But I believe we don't have something like leftsubnets=%radius right? (probably it would be ugly to do so with IKEv2, best would be to just implement that IKEv2 attribute handler)

Were I to implement a handler for INTERNAL_IP4_SUBNET where the routes in the attributes are installed into the routing table, would TS negotiation phase overwrite the routes installed by the handler? Or, if I am interpreting source:src/libcharon/plugins/unity/unity_handler.c#L69-L85 correctly, would it be a better approach to adjust the client's TS proposal based on the attribute payload received?

Thanks.

But I believe we don't have something like leftsubnets=%radius right?

The eap-radius plugin could theoretically implement the narrow() hook on listener_t to change the traffic selector that's installed and sent back to the client.

INTERNAL_IP4_SUBNET works differently (see #2185-1 regarding some of my concerns). It would certainly work with route-based VPNs, but that's a special case.

Were I to implement a handler for INTERNAL_IP4_SUBNET where the routes in the attributes are installed into the routing table, would TS negotiation phase overwrite the routes installed by the handler?

Routes are not IPsec policies, but depending on the client that's theoretically an option (e.g. on Android or other route based VPNs).

Or, if I am interpreting source:src/libcharon/plugins/unity/unity_handler.c#L69-L85 correctly, would it be a better approach to adjust the client's TS proposal based on the attribute payload received?

As mentioned, the eap-radius plugin could probably do something similar. It's also possible to do that on the client (i.e. narrow the TS right before installing them, but the server would probably have to do the same).

Tobias Brunner wrote:

But I believe we don't have something like leftsubnets=%radius right?

The eap-radius plugin could theoretically implement the narrow() hook on listener_t to change the traffic selector that's installed and sent back to the client.

INTERNAL_IP4_SUBNET works differently (see #2185-1 regarding some of my concerns). It would certainly work with route-based VPNs, but that's a special case.

Were I to implement a handler for INTERNAL_IP4_SUBNET where the routes in the attributes are installed into the routing table, would TS negotiation phase overwrite the routes installed by the handler?

Routes are not IPsec policies, but depending on the client that's theoretically an option (e.g. on Android or other route based VPNs).

Or, if I am interpreting source:src/libcharon/plugins/unity/unity_handler.c#L69-L85 correctly, would it be a better approach to adjust the client's TS proposal based on the attribute payload received?

As mentioned, the eap-radius plugin could probably do something similar. It's also possible to do that on the client (i.e. narrow the TS right before installing them, but the server would probably have to do the same).

This is very helpful, thank you Tobias. The workarounds you suggest indeed would save the day.
The sentence from your earlier reply Since the attributes are exchanged only after the client already proposed the traffic selectors clarifies why it's implementation is a bit in the grey-area. Don't you think INTERNAL_IP4_SUBNET seems to be destined to be applicable for route-based VPNs only? Could Childless SA be an elegant approach?

Alan