[Swan] IPv4 over IPv6 tunneling

Wed May 13 09:17:36 UTC 2020

After a very long night of fighting around, I finally found the solution to this issue.

When the Encapsulation Limit option of IPv6 is set, which is the default in conjunction with ip6gre or ipip6 tunnel interfaces on Linux systems, the driver creates the «Destination Options for IPv6» header and appends it to the IPv6 header of the packet. If for some reason the other end, which in this case the Cisco box was, doesn't support outer packets with the «Destination Options» header, the entire «Destination Options» header can be eliminated by setting the Encapsulation Limit option to "none".

> [root at ip-10-0-10-200 network-scripts]# ip -6 tunnel change tun10 encaplimit none
> [root at ip-10-0-10-200 network-scripts]# ip -6 tunnel
> ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit inherit tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
> tun10: ip/ipv6 remote <remote-ipv6-addr> local <local-ipv6-addr> encaplimit none hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)

Since the Encapsulation Limit option cannot be set via the ifcfg scripts (/etc/sysconfig/network-scripts/ifcfg-xxx), the tunnel interface has to be created manually, either in the /etc/rc.conf file or as a shell script, called via custom service.

Hope it'll be helpful to somebody one day :)

Cheers,

jellybeanshiba

________________________________
Von: Swan <swan-bounces at lists.libreswan.org> im Auftrag von Liam Schönberg <liam.ch at outlook.com>
Gesendet: Donnerstag, 7. Mai 2020 16:57
An: swan at lists.libreswan.org <swan at lists.libreswan.org>
Betreff: [Swan] IPv4 over IPv6 tunneling

Dear Community,

Since the most important Telco in Switzerland, Swisscom (Schweiz) AG, is clearly doing some kind of traffic engineering, where tunneling packets (GRE or IP-in-IP) over IPv6 get far less prioritized, resulting that the throughput in conjunction with (clear-text) IPv4 over IPv6 tunnels is dramatically lower than the throughput of regular IPv6 traffic (TCP or UDP), I'm trying to implement GRE over IPsec over IPv6, so that the IPv4 traffic can travel over the IPv6 Internet smoothly.

But I'm having a difficulty setting up the tunnel in the following configuration and was hoping anybody could assist me resolving the issue:

Site-A:
Libreswan 3.25 on Amazon Linux 2
leftsubnet=«Site-A»/128

Site-B:
Cisco C897VA-K9 running IOS 15.7(3)M6
leftsubnet=«Site-B»/128

Underlying Protocol: IPv6
Main Mode: IKEv2, AES-CBC-128, SHA1-96, MODP2048
Quick Mode: ESP, AES-CBC-128, SHA1-96, MODP2048
Type: Transport (instead of Tunnel)

There's a GRE over IPv6 («ip6gre») tunnel configured on both Site-A and Site-B.

# ip link add type ip6gre local «Site-A» remote «Site-B»
# ip address add 169.254.20.1/30 dev ip6gre1

! interface Tunnel20
!  ip address 169.254.20.2 255.255.255.252
!  tunnel source «Site-B»
!  tunnel destination «Site-A»
!  tunnel mode gre ipv6

Without applying the IPsec policies via Libreswan or Crypto-Map, both sides do have a reachability through the GRE over IPv6 tunnel, when I ping their addresses (169.254.10.1 or 169.254.10.2). When I then apply the IPsec policies on both sides, the (IPv4) reachability goes away.

I did make sure that the SPIs are showing up on both sides, when I generate those GRE packets, but the Cisco side looks like having difficulties processing the encrypted packets.

When the Linux side generates a GRE (over IPv6) packet, it adds those «Destination Options», which includes the «Tunnel Encapsulation Limit» and «PadN» options, in the IPv6 header. Since we're running on the «Transport» mode, those IPv6 headers don't get modified, leaving those «Destinations Options» as they are, even after the encryption.

Those packets then arrive on the Cisco side, get decrypted – wrongly. Somehow, after the decryption, the Cisco's code doesn't set the first «Next-Header» option in the IPv6 header to be «Destination Options», but instead, it sets «GRE». Inevitably, it then fails to process those packets as GRE packets, since the payload of those packets actually begin with the «Destination Options» portion, which actually belongs to the IPv6 header, instead of the GRE header.

Before encryption:
IPv6, next header: Destination Options
IPv6 Destination Options, next header: GRE
GRE (original payload)

After encryption:
IPv6, next header: Destination Options
IPv6 Destination Options, next header: ESP
ESP, next header: GRE
GRE (original payload)

After decryption:
IPv6, next header: GRE
IPv6 Destination Options, GRE (corrupt payload)

Here are the possibilities I went through:

- Using other encryption algorithms, such as AES-GCM or even Null.
- Trying both IKEv1 and IKEv2.
- Specifying the exact protocol (GRE, IP Protocol 47) as interesting traffic, instead of IPv6 entirely.
- Using other tunnel interface types, such as IP6TNL.
- Using other Linux distributions, such as RHEL and Ubuntu.

Unfortunately, none of them actually worked. Since I took every time a packet capture, decrypted those ESP packets with Wireshark and saw the resulting packets with the wrong «Next-Header» option, I'm almost sure that it is not a configuration issue.

The only thing that helped was, sadly, to set the IPsec mode to «Tunnel», instead of «Transport». That way, the entire IPv6 header with its payload were to get decrypted without getting corrupted on the Cisco side. But this workaround would be subject to the extra overhead of 40 bytes, which would father reduce the resulting MTU of the inner tunnel. In my case, it would be 1390-48-4=1338. Again, those 4 bytes are the «Destination Options», which I don't understand why it's there in the first place. The Cisco side doesn't add those 4 bytes – Is there any way to prevent the Linux kernel from adding those options, when running GRE over IPv6? Or a way, where the ESP stack can ignore/remove those «Destination Options», when running on Transport mode?

To be honest, I have no clue about which side, either the Linux side, Cisco side or both, is doing it wrong, but I really want to get it working with the Transport mode. Please let me know, if anybody knows how it could be achieved.

Best regards,

jellybeanshiba
_______________________________________________
Swan mailing list
Swan at lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200513/a25c00e1/attachment.html>