BUG: ip6tables IPv6-REDIRECT over bridges

BUG: ip6tables IPv6-REDIRECT over bridges

[Artie Hamilton]

Hi,

I have currently following setup with three devices (actual 3 hardware boxes)

box1       box2                              box3
client --> (eth0)[bridging device](eth1) --> service x


The bridging device checks the properties of "client" and maybe redirects
him to a server on the bridging device (just assume HTTP for now). The
user is then welcomed and some instructions are shown. Before anyone
asks: NO, this is not a security mechanism.

The bridging device is a linux device and currently works perfectly fine with
IPv4 redirections. It is done (heavily simplified version) by running.

$ brctl addbr br0
$ brctl addif br0 eth0
$ brctl addif br0 eth1
$ ip addr add 192.168.1.42/24 dev br0
$ sysctl -w net.bridge.bridge-nf-call-iptables=1
$ iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81

This works perfectly fine with IPv4 services. Everyone is happy about the
bridged setup and the extra functionality with special redirects for this IPv4
service.

Now the same thing should be done for IPv6. It should works quite similar
(I just assume the above mentioned steps are already done):

$ sysctl -w net.ipv6.conf.br0.accept_ra=2
$ sysctl -w net.bridge.bridge-nf-call-ip6tables=1
$ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81

But here is the problem: Connections will not be started. I see for example
connections getting started to the service like this on the client:

$ curl -6 -D - 'http://\[2001:1234::1\]:8080/'
..... nothing .....

A dump shows as first packet at tcp SYN to the service 2001:1234::1 with port
8080. And sometimes I see following too:

 * ICMPv6 redirect reply
 * SYN+ACK from fde9:....:d320 (one of the addresses of br0 but not
   from the actual range 2001:..../64) with port 81 !!!!!!!!!
 * RST from client to fde9:....:d320 with port 81

This seems to be a bug in nat or conntrack, right?

The conntrack event output show this:

    [NEW] tcp      6 120 SYN_SENT src=2001:...::3 sport=49495 dport=8080 [UNREPLIED] src=fde9:....:d320 sport=81 dport=49495

I've also tried following setups:

 * bridge setup but DNAT to service y (some server next to service x)
   $ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j DNAT --to-dest [2001:1234::2]:81
   => works
 * routing setup (br0 only contains eth0 and eth1 is a separate device)
   $ iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81
   => works

When I use curl on the IPv6 address of the bridge device (2001:1234::1337) then
it works on the actual server port 81 and the port which should get redirected
to 81 - port 8080:

$ curl -6 -D - 'http://\[2001:1234::1337)\]:81/'

HTTP/1.1 200 OK
....
$ curl -6 -D - 'http://\[2001:1234::1337)\]:8080/'
HTTP/1.1 200 OK
....

It really seems to be a bug when doing DNAT/REDIRECT with bridges and IPv6. And
it is not possible for me to change the previously mentioned setup to a routed
setup.

I've also read a little bit about TPROXY but found no good way to use it
together with this bridged setup without routing rules (but worked quite well in
routing).

Re: BUG: ip6tables IPv6-REDIRECT over bridges

[Florian Westphal]

Artie Hamilton <artiemhamilton@yahoo.com> wrote:
> Now the same thing should be done for IPv6. It should works quite similar
> (I just assume the above mentioned steps are already done):
> 
> $ sysctl -w net.ipv6.conf.br0.accept_ra=2
> $ sysctl -w net.bridge.bridge-nf-call-ip6tables=1
> $ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81
> 
> But here is the problem: Connections will not be started. I see for example
> connections getting started to the service like this on the client:

Yes, because bridge layer does not detect when addresses have been
rewritten.

The check is only implemented for ipv4, see dnat_took_place use in br_netfilter.c
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html