Issue #447
how to make strongSwan as a responder distinguish between different conns
Description
I have two conns which only have a single difference: One is set up to provide an IPv4 address with rightsourceip, and the other one is set up to provide an IPv6 address.
However, strongSwan always chooses the conn that is supposed to provide the v4 address, so negotiation always fails, when I want to bring the v6-conn up.
The config is the same as the one from issue #446. I tried giving the v6-conn a different leftid, but it seems strongSwan doesn't take the value into account when choosing the configuration.
I try to bring up the v6-conn after the v4-conn, as I want to have access with both protocols.
The log shows both conns getting the same priority (1052), but as the v4-conn is above the v6-conn in the file, it gets chosen.
History
#1 Updated by Tobias Brunner almost 12 years ago
- Category set to configuration
- Status changed from New to Feedback
- Assignee set to Tobias Brunner
I tried giving the v6-conn a different leftid, but it seems strongSwan doesn't take the value into account when choosing the configuration.
This depends on the client. If it does not send an IDr payload there is nothing to compare with. This might be on purpose (e.g. with Windows 7/8 clients or our Android and Mac OS X apps) to allow the gateway to use a different identity than the client uses to verify the gateway (e.g. if it uses the hostname but the gateway uses the certificates DN). So to select a specific config you'd have to make sure you configure a matching rightid on the client.
I try to bring up the v6-conn after the v4-conn, as I want to have access with both protocols.
Well, the question is why two connections then. It depends on the client, but with Windows or strongSwan clients you could just configure:
conn thinkpad ... leftsubnet=0.0.0.0/0,::/0 rightsourceip=172.16.20.0/24,2a01:1e8:e100:4ca:00ca:1/64 ...
And on the client:
conn thinkpad-client ... rightsubnet=0.0.0.0/0,::/0 leftsourceip=%config4,%config6 ...
#2 Updated by Noel Kuntze almost 12 years ago
The notation you used work.
I tried to use these lines instead:
leftsubnet=0.0.0.0/0, ::/0
rightsourceip=172.16.20.0/24, 2a01:1e8:e100:4ca:00ca:1/64
Those have a space between the arguments, which has caused errors like this on reload/update/restart:
Nov 16 11:41:50 vms.thermi ipsec[402]: /etc/ipsec.conf:54: syntax error, unexpected STRING, expecting EOL [::/0]
This led me to believe it wasn't supported. Thanky you for your help.
I now ran into the error from #446 (29[KNL] received netlink error: Invalid argument (22)).
#3 Updated by Tobias Brunner almost 12 years ago
- Status changed from Feedback to Closed
- Resolution set to No change required