[strongSwan] IPv6 routing cycle

Wed Nov 27 01:44:49 CET 2013

Thanks this seemed to have gotten the packets at least flowing out my private interface! :)

However now I am seeing  neighbor solicitation requests. Any idea how I can fix this? Has any encountered similar issues with IPv6? I have been at it all day and no luck.

tcpdump -i eth1 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
18:38:02.037385 IP6 fc00::2:2 > fc00::1: ICMP6, neighbor solicitation, who has fc00::1, length 24
18:38:02.037402 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 5, length 16
18:38:03.030709 IP6 fc00::2:2 > fc00::1: ICMP6, neighbor solicitation, who has fc00::1, length 24
18:38:03.036043 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 6, length 16
18:38:04.032282 IP6 fc00::2:2 > fc00::1: ICMP6, neighbor solicitation, who has fc00::1, length 24
18:38:04.036594 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 7, length 16
18:38:05.042445 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 8, length 16
18:38:06.042342 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 9, length 16
18:38:07.042308 IP6 fc00::2:2 > fc00::1: ICMP6, echo request, seq 10, length 16
18:38:07.048801 IP6 fc00::1 > ff02::1:ff02:2: ICMP6, neighbor solicitation, who has fc00::2:2, length 32

Regards,

Adrian Milanoski
Lab Administrator
BBOS WiFI VPN. Security Testing – R&D
Tel.(289) 261-5801 | Cel: (647) 289-261-5801
Email  amilanoski at blackberry.com

-----Original Message-----
From: Andrej Podzimek [mailto:andrej at podzimek.org] 
Sent: Wednesday, November 20, 2013 5:09 AM
To: Adrian Milanoski; Noel Kuntze; users at lists.strongswan.org
Subject: Re: [strongSwan] IPv6 routing cycle

Hi,

I've just found a configuration that works for me. The basic idea: For some reason, routes through the tunnel work when added by StrongSwan, but don't work when added manually. This leads to the obvious question: How to make StrongSwan configure the default route?

This is how I did it: The server is willing to route *any* IPv4 or IPv6 subnet. This means that the Road Warrior (RW) is completely free to select the subnets to route through the server, including the IPv6 or IPv4 default route. All other IPv{4,6} addresses will be accessed directly, using the RW's unencrypted network.

On the server:

conn    warrior
         left=%defaultroute
         leftsubnet=::/0,0.0.0.0/0
         leftcert=server.crt
         leftid=@your.server.id
         right=%any
         rightid=@your.warrior.id
         rightsourceip=2a01:xxxx:xxxx:xxxx:5::/80,10.0.5.0/24
         auto=add

When the RW has IPv6 access and only wants to access the server's subnets securely; all other traffic will be routed unencrypted:

conn    access46
         left=%defaultroute
         leftid=@your.warrior.id
         leftcert=warrior.crt
         leftsourceip=%config6,%config4
         right=your.server.dns.name
         rightid=@your.server.id
         rightsubnet=2a01:xxxx:xxxx:xxxx::/80,2a01:xxxx:xxxx:xxxx:1::/80,2a01:xxxx:xxxx:xxxx:2::/80,2a01:xxxx:xxxx:xxxx:3::/80,2a01:xxxx:xxxx:xxxx:4::/80,server.public.ipv4,10.0.1.0/24,10.0.2.0/24,10.0.3.0/24,10.0.4.0/24

When the RW doesn't have IPv6 access and wants to route all IPv6 traffic through the server (while IPv4 traffic remains "split"):

conn    access4route6
         left=%defaultroute
         leftid=@oyour.warrior.id
         leftcert=warrior.crt
         leftsourceip=%config6,%config4
         right=your.server.dns.name
         rightid=@your.server.id
         rightsubnet=::/0,10.0.1.0/24,10.0.2.0/24,10.0.3.0/24,10.0.4.0/24
         auto=add

Note the ::/0 at the beginning of rightsubnet; that does the magic for me. :-) It should be possible to create a variant that would route IPv4 through the tunnel as well, if desired (by setting 0.0.0.0/0 instead of the private IPv4 ranges on the client). In addition to the configuration above, I use {left,right}firewall=no and a few other options (related to my CA and CRL).

In the latter RW configuration, you have to make sure that the IPv6 default route appears in table 220 and *only* in that table; it can quickly get overridden by router advertisements from the local network, causing *all* your IPv6 traffic to flow unencrypted. The specific IPv6 routes in the former RW configuration are not prone to such unexpected changes, unlike the default route.

Cheers,
Andrej

> I ma in the same situation myself right now and my IPV6 traffic traveling over a ipv4 tunnel reaches the GW‎ and I can only ping6 the internal address of the GW.
>
> If I try and ping6 another device behind the GW I don't see a single packet go out any interface.
>
> Is ipv4 to ipv6 even supported by strongSwan?
>
>
> Regards,
> Adrian Milanoski
> Lab Administrator
> BBOS WiFi VPN Security Testing. - R&D
> Tel.(289) 261-5801 | Cel: (647)289-6995
> Email: amilanoski at blackberry.com
> Berried into cloud 10 da next level!l!..
>    Original Message
> From: Noel Kuntze
> Sent: Tuesday, November 19, 2013 12:07 PM
> To: Andrej Podzimek; users at lists.strongswan.org
> Subject: Re: [strongSwan] IPv6 routing cycle
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Andrej,
>
> I encountered the exact same problem with my own setup with exactly the same behaviour.
> If you found a solution, please let me know.
>
> Regards
> Noel Kuntze
>
> On 19.11.2013 17:44, Andrej Podzimek wrote:
>> Hello,
>>
>> my question might not be directly related to StrongSwan... I'm facing a routing problem when I try to direct IPv6 traffic through a default gateway over IPSec. A road warrior (RW) and a server both run StrongSwan 5.1.1 on ArchLinux. The RW is on an IPv4-only network behind NAT and the goal is to give the RW a full IPv6 access via the server, i.e., not only the access to the server's network.
>>
>> The server and the RW can ping6 one another and the tunnel between them seems to work fine.
>>
>> Unfortunatey, the RW cannot use the server as a default route. Despite the fact that the RW obtains a publicly routable IPv6 address from the right range, it can only ping6 the server's IPv6 addresses. No other machines can be contacted by the RW over IPv6. And vice versa, other machines cannot ping6 the RW either, although IPv6 works fine for them otherwise.
>>
>> The tcpdump output on the server (tcpdump -i any icmp6) is surprising: When I try to ping6 the RW through the server from outside, it seems that the server doesn't figure out that the packets need to be forwarded through the tunnel and resends it to itself until the hop limit is reached. A huge number of these cyclic retransmissions appears on tcpdump. Furthermore, I can see ICMPv6 redirects sent by the server that redirect the ping packets to the *same* IPv6 address over and over (both "from" and "to" are the same -- it's the address of the RW).
>>
>> Packets are silently swallowed in the other direction: Packets sent from the RW to a remote machine do *not* appear on the server's tcpdump at all, so for some reason they don't make it through the IPSec tunnel.
>>
>> Otherwise routing works normally on the server, i.e., there is a LAN network behind it with an ethernet subnet, a WiFi AP subnet and an OpenVPN subnet. Clients on all these subnets can use IPv6 just fine. So the IPSec problem may not be just a glitch with disabled forwarding or the like. :-)
>>
>> Additionally, the IPSec tunnel also has IPv4 private addresses configured. Unlike IPv6, IPv4 works flawlessly there -- the RW can ping4 and access machines from the server's networks (including the server) and vice versa. (However, for IPv4, the server is not configured as the RW's default gateway.)
>>
>> I set the RW's IPv6 default gateway to the server's 'src' IPv6 address (obtained from routing table 220 on the server). The RW can ping6 that address and the server can ping6 the RW back, so I thought that the server could be a default gateway for the RW. The routing tables 220 created by StrongSwan look OK on both the RW and on the server.
>>
>> As for other possible causes of the problem, the server doesn't route "back through the same interface" in this case, because the IPSec IPv6 packets emerege from the IPv4-only eth0 interface, whereas IPv6 packets to/from remote machines use 6to4 tunnels -- separate virtual interfaces distinct from eth0.
>>
>> When speaking about routing, the RW's IPv{4,6} addresses have prefixes distinct from all the other networks interconnected by the server, so all communication to/from IPSec tunnels should be simply routed -- there should be no need for bridging, farp or for a hypothetical NDP equivalent of farp...
>>
>> One more thing: I don't use {left,right}firewall, because I have my own (quite lengthy) iptables configuration that lets the IPSec traffic through. Disabling iptables completely did not help; the issue was still exactly the same -- packets disappearing in one direction and bouncing back crazily in in the other direction.
>>
>> Well, I'm running out of ideas and I badly need a piece of advice. :-)
>>
>> Cheers,
>> Andrej
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSi5qvAAoJEDg5KY9j7GZYg2MP/A8MldG+FWMV371I3lgtEscP
> oDQ+mX+9YBm5QkMlNIMmirBwN60GvMaL1UfjOwQtzy2p1fqRhNYSszXsNBc4fXFw
> WdidfvQ13a6DKM5K6GpGZSQwJf9uU+9rhBGDySr5tixng8JuTlnc3JZNywrbNrms
> 8gyiWXvilWCXZNeViWKI0827KS/KjunlOATiDZt53vMSdigqbnsSm+DD+jrIxOuL
> CHGwgc1/eOXXd7AfEd/OCQhFbgdtihXWzI/Rt8k2q4awUf7+kWRdotFRraTIPBC/
> FZ/ngnux9x19UWxzoxsYZcoe4aIlbfkw7En72kkSyq9cxyJZ9NtAXoMuVZg7GcdG
> 2+JzKQGbxD7/UZ9PKKrm+xamdUshNeRB/XZ/0z9V/4TZU3ijE0dNbg+0RS/Dm/64
> k38c4O4ifyET9EwkxrwZraXaL2AkZoVb14Kk//8gX0MigRwhLiRhNFqYDbm9mluu
> faJ839wUffj5PLIDLKO9M4omNigskZk3ILiAtNWNQ2mReAb0vtrY/C7NjH7bKtnh
> ZVncABBfVsF+xZGTO1JpkywF4ALYgVF1p3gixHE5VlOIBY58a0g53H7V8N5emWO2
> aQyTjKRTtpK92XlbovyFiq7MRYvIRL6yPCJR19wmf1SCN2MdxJrOlY+lPMGGtQ7G
> Owcsx9OOFC/QpHTs8B4x
> =IYWN
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.