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
