Bug#894403: linux-image-4.14.0-0.bpo.3-amd64: NAT66 (IPv6 SNAT masquerade) does not rewrite source address on kernel 4.14

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + moreinof

On Thu, Mar 29, 2018 at 09:40:38PM +0100, Rob Andrews wrote:
> Package: src:linux
> Version: 4.14.13-1~bpo9+1
> Severity: normal
> 
> Dear Maintainer,
> 
> I use Docker for application segregation on a remote server. The host has a single v4 and a single v6 IP address allocated. On the host system, I have NAT66 (SNAT, masquerading) setup with the following rules in order to provide segregated IPv6 connectivity to Docker containers:
> 
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     0     0 DOCKER     all      any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     0     0 DOCKER     all      any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL
> 
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     0     0 MASQUERADE  all      any    docker0  anywhere             anywhere             ADDRTYPE match src-type LOCAL
>     0     0 MASQUERADE  all      any    !docker0  fd00:bee:cafe::/64   anywhere            
> 
> Chain DOCKER (2 references)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> On the standard stretch 4.9.x kernel, NAT66 works just fine as witnessed by this tcpdump of a ping (note that the 2001:: address is that of the AAAA record for debian.org):
> 
>   % sudo tcpdump -i ens3 -n 'not tcp and not udp'
>   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>   listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
>   19:56:24.980979 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 0, length 64
>   19:56:24.988597 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: ICMP6, echo reply, seq 0, length 64
>   19:56:25.981716 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 1, length 64
>   19:56:25.989010 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: ICMP6, echo reply, seq 1, length 64
>   19:56:26.982894 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 2, length 64
> 1  9:56:26.990022 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: ICMP6, echo reply, seq 2, length 64
> 
> Whilst on the backports kernel 4.14.x, NAT66 fails to rewrite the source address, and all IPv6 traffic (not just ICMP) fails as a result:
> 
>   % sudo tcpdump -i ens3 -n 'not tcp and not udp'
>   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>   listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
>   20:00:39.711554 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 0,length 64
>   20:00:40.712591 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 1,length 64
>   20:00:41.713768 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 2,length 64
>   20:00:42.714934 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 3,length 64
>   20:00:43.716088 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 4,length 64
>   20:00:44.717264 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: ICMP6, echo request, seq 5,length 64
> 
> The expected behaviour is what is witnessed with kernel 4.9.x - the source address is rewritten with the outgoing interface address.
> 
> Ignoring the Docker aspect of this, the witnessed behaviour can be reproduced without having to use a container: use 'ping6 -I <my-ula-address> debian.org'. You'll need to setup some NAT66 rules and create a virtual interface with a ULA address to simulate the behaviour - this stanza in an interfaces file will suffice (make sure you have bridge-utils installed):
> 
>   iface br-nat-virt inet6 static
>   	bridge_ports none
>   	address fd00:bee:f00d:cafe::1/64
> 
> And the following NAT66 rule:
> 
>   ip6tables -A POSTROUTING -s fd00:bee:f00d:cafe::/64 ! -o br-nat-virt -j MASQUERADE
> 
> Then reproduce the behaviour using 'ping6 -I fd00:bee:f00d:cafe::1 debian.org'.
> 
> I hope this makes sense. It's not a major biggy, I'm just falling back to using the non-backports kernel in stretch in the meantime.

is this issue still reproducible with a recent kernel from unstable or
buster backports?

Regards,
Salvatore