[strongSwan] Traffic Selector problem when using IKEv2 IPV6

Eric_C_Johnson at Dell.com Eric_C_Johnson at Dell.com
Tue Jan 31 18:06:22 CET 2012


Hi.

I am having extreme difficulty authenticating IKE to a remote peer from my Strongswan host using IKEv2 and IPv6 when specifying leftprotoport\rightprotoport.

Let me clarify by saying I can authenticate and establish the tunnel if I only specify the protocol value in the protoport designations  (E.g. leftprotoport=tcp + rightprotoport=tcp).  When I use this convention the traffic selectors appear as the following on the remote peer:

Find a rule matching the first traffic selectors of: TS_r=ipv6(tcp:3260,fc00:2518::10:125:56:16),ipv6(tcp,fc00:2518::10:125:56:16) and TS_i=ipv6(tcp,fc00:2518::221:9bff:fe98:854b),ipv6(tcp,fc00:2518::221:9bff:fe98:854b)

In this case, the traffic selectors from the Strongswan host appear to be sending tcp,fc00:2518::221:9bff:fe98:854b.  Which appear fine since I didn't specify any port values in the protoport designations.

However, when I specify a port value in the protoport designations (E.g. leftprotoport=tcp/0 + rightprotoport=tcp/3260 OR leftprotoport=6/0 + rightprotoport=6/3260 OR leftprotoport=tcp/any + rightprotoport=tcp/3260), the IKE authentication fails due to a traffic selector mismatch.  When I use any of the previous conventions the traffic selectors appear as the following on the remote peer:

Find a rule matching the first traffic selectors of: TS_r=ipv6(tcp:3260,fc00:2518::10:125:56:16),ipv6(tcp:3260,fc00:2518::10:125:56:16) and TS_i=ipv6(tcp,fc00:2518::221:9bff:fe98:854b),ipv6(tcp,fc00:2518::221:9bff:fe98:854b)

In this case, the traffic selectors from the Strongswan host appear to be sending tcp,fc00:2518::221:9bff:fe98:854b.  Which do not appear fine since I specified the port values in the protoport designations.  In fact they appear to be exactly the same as when I didnät specify the port values in the protoport designations.  So I guess the question is why are the port values from the Strongswan host not being presented to the remote peer?  Has anybody else seen this before?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120131/f078fb17/attachment.html>


More information about the Users mailing list