[strongSwan] IPv6 routing cycle

Wed Nov 20 06:40:07 CET 2013

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.