[strongSwan] "next header type" issues with ipv6 tunnel

[Christian Becker]

The tunnel is working now since i replaced the router (Speedport W 901V) with a different Model (FritzBox in this case).

A bit of further digging showed some posts in the “community forums” of Deutsche Telekom. There are not that much posts containing ESP, since IPsec is pretty heavy stuff and it looks as their reason for this is to prevent the use of consumer ADSL lines by businesses. [1]

But all measures seem to be subtle on the routers provided for consumers and there seems to be no filtering besides of that. (For clarification - my IPsec Tunnel is outgoing - incoming wouldn’t be possible with their provided router, because it doesn’t allow the creation of IPv6 Firewall rules for incoming traffic and the IPv4 options are also heavily limited to some basic TCP/UDP forwards).

In my case, IPv4 was working all the time (though i didn’t get IPv6 over IPv4 running, but i guess it’s been my mistake) and just ESP over IPv6 was affected. After replacing the router the tunnel came up and traffic was flowing without issues (i’m glad they allow “custom” hardware - german providers are bitchy in this case - they insist that the router is part of their “network” and some providers doesn’t hand you the required credentials for using own hardware).


For those who are curious, i checked the IPv6 rfc2460 [2] which states: “With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.” (the exception is a “hop-by-hop” indicator which is not present in ESP packets).

Since their behavior is a “violation” of this RFC i created a ticket asking for clarification but haven’t heard anything yet.

Cheers,
Christian

[1] https://telekomhilft.telekom.de/t5/forums/searchpage/tab/message?filter=labels%2Clocation&location=community%3Ariokc95758&q=esp (german only)
[2] https://tools.ietf.org/html/rfc2460#section-4

> On 06.04.2015, at 06:09, Christian Becker <phpbeck at gmail.com> wrote:
> 
> Hi,
> 
> i’m trying to setup a tunnel over ipv6 and get the SAs installed.
> 
> My problem is now, that if i send a ping over this tunnel, i’ll don’t get responses and in tcpdump i see
> 
> out > next-header ESP (50)
> in   > next-header ICMPv6 (58) => ICMP6, parameter problem, next header - octet 6
> 
> the answer is send by my local gateway / router / ipv4 nat box (which is unfortunately a blackbox i got from my provider)
> 
> Wireshark reports the message as: Code: 1 (unrecognized Next Header type encountered)
> 
> Unfortunately i just found RFCs containing this message and no useful information.
> 
> Is there a way to encapsulate the packets to avoid this or do i have to tell my provider to fix this? I already tried to use “forceencaps”, but this causes netlink issues on my vpn box.
> 
> Thank you,
> Cheers,
> Christian
>