does anyone have a solution to make reverse path filtering work (in loose mode) also for IPv6 and not only for IPv4?

The setup I am having is a machine1 connected directly to a machine2, while machine1 being also connected to outside net.

The targetted traffic is this: Client (from the outside net) sends a request to the machine1 which then forwards the request to the machine2.

Obvious problem: When packet gets handled by machine1, it forwards it to a port connected to machine2, but with source IP of a client. This would normally be seen as a spoofed ip - but that's what rp_filter is for, right?

Normally on machine1 I would do (for IPv4): echo 2 > /proc/sys/net/ipv4/conf/<interface_to_outside_net>/rp_filter and everything would work, but for IPv6 this is not the case since rp_filter is not implemented in the kernel for IPv6 as of yet. The only solution I know of would be to set up ip6tables.

Current settings: ip6tables -t raw -N RPFILTER ip6tables -t raw -A RPFILTER -m rpfilter -j RETURN ip6tables -t raw -A RPFILTER -m rpfilter --loose -j ACCEPT ip6tables -t raw -A PREROUTING -j RPFILTER

But for some reason traffic never reaches machine2 and on the client side I get timeout.

Using tcpdump on machine1 I get only the SYN of TCP handshake.:

14:18:50.390292 IP6 fd11:3456:789a:1::4.34184 > fd12:3456:789a:1::1.1111: Flags [S], seq 701159610, win 28800, options [mss 1440,sackOK,TS val 6066549 ecr 0,nop,wscale 7], length 0

nothing else...

Any advice?

  • What Linux distribution did you use? What kernel version? What firewall? – Michael Hampton Nov 26 '18 at 15:54
  • OS Ubuntu 18.04 (xenial), kernel 4.4.0-139-generic, firewall not configured at all. Those commands above are the first I used. Default policy is set to ACCEPT if I check iptables. – Diavel Nov 27 '18 at 7:47
  • I also tried running only with ip6tables -t raw -A PREROUTING -m rpfilter --loose -j ACCEPT .. but did not help – Diavel Nov 27 '18 at 12:05
  • 1
    Are you sure that machine1 is actually routing traffic? – Michael Hampton Nov 27 '18 at 12:08
  • Well it should be (again its doing the routing for IPv4), but something's gotta be wrong for IPv6. I am tracing the packets in iptables now. – Diavel Nov 27 '18 at 12:42


The problem was actually related to the fact that I did not set up the IPv6 addresses using /etc/network/interfaces/ but "only" using ip a a .... I never thought that this could somehow be a different, but it turned out to be the case this time.

STEPS leading to SOLUTION:

During the investigation I did a simple ping6 from machine2 towards machine1 which strangely fixed the problem I was having.

After this, the TCP handshake got correctly created and I was able to do a curl -g -6 .. which was the target command I wanted to do and I was like YES finally!

But then I was like ...this doesn't make sense, why is ICMPv6 not taking care of this? This made me thinking that I should check ndp (ip -6 neigh show) table which actually showed me that entry for machine1 had FAILED.

Which means that for some reason ICMPv6 was failing to exchange neighbor solicitations/advertisements.

At the end I remembered that simple pc reboot usually fixes all the problems, but since I configured my interfaces using only ip a a ... this would flush my configuration, so what I did was configured /etc/network/interfaces/ with proper IPv6 addresses and rebooted machines.

This was the source of all the problems ;)


Don't do anything in regards of rp_filter in loose mode for IPv6 ==> it's enabled by default.

Just make sure, that you have properly configured your interfaces :)

PS: Does anyone know what I messed up? Why wasn't I able to simply use ip address add....? Thanks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.