Issue #2580
[CFG] handling xx attribute failed in Android or Ubuntu, but works in macOS
Description
Hi,
I applied the following patches for translating RADIUS attributes to IKEv2 equivalent for split-tunnel and split-dns.
https://github.com/kthkaya/strongswan/commit/98105a8a39b53710e0ad072e037e0b69522a8055
https://github.com/kthkaya/strongswan/commit/a2049bfc44bb2a18cafed84fb8da2c2d7b9b87f3
Split-tunnel routes are stored in the form of Address1/Netmask1,Address2/Netmask2 in RADIUS. Then each Address1/Netmask1 is contained within an individual attribute payload as described in the RFC.
Same goes for split-dns. The only difference is the separator (" " instead of ",") at RADIUS.
It works with the native VPN adapter of macOS. The pushed routes correctly appear in the route table, and the pushed domains correctly appear in scutil --dns. Everything OK!
However in Android using strongSwan VPN client, and in Ubuntu using network-manager-strongswan, I get the following errors.
15[CFG] handling (25) attribute failed
15[CFG] handling INTERNAL_IP4_SUBNET attribute failed
Looks like some trivial encoding issue. Can you point me to the right direction?
Regards,
Alan
History
#1 Updated by Tobias Brunner over 4 years ago
- Status changed from New to Feedback
However in Android using strongSwan VPN client, and in Ubuntu using network-manager-strongswan, I get the following errors.
15[CFG] handling (25) attribute failed
15[CFG] handling INTERNAL_IP4_SUBNET attribute failedLooks like some trivial encoding issue. Can you point me to the right direction?
Nope, strongSwan currently does not support these attributes.
#2 Updated by Scep CAfail over 4 years ago
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.
#3 Updated by Tobias Brunner over 4 years ago
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).
#4 Updated by Scep CAfail over 4 years ago
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 onlistener_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