[FS#500] firewall3: missing targets with IPv6 NAT

LEDE Bugs lede-bugs at lists.infradead.org
Sat Aug 26 02:42:20 PDT 2017


The following task has a new comment added:

FS#500 - firewall3: missing targets with IPv6 NAT
User who did this - Nathaniel Wesley Filardo (nwf)

----------
Several places in the firewall3 code for handling redirects explicitly reject IPv6, despite what's hinted in the documentation and the... shall we say somewhat aspirational inclusion of a 'family' parameter.

Looking at

https://git.lede-project.org/?p=project/firewall3.git;a=blob;f=redirects.c;h=e651dddef381375a912d4d3882e49b3ef0cdcf21;hb=HEAD

the initial positions that stand out are lines 119, 243, 256-258, 275, 413, 630-631, and 650.  All of these would seemingly need IPv6 analogs in order for redirects to work properly.

I've taken the wimp's way out and just added what I need to /etc/firewall.user:

ip6tables -A forwarding_wan_rule -m conntrack --ctstate DNAT -j ACCEPT
ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set --match-set me6 dst -j DNAT --to-destination '[fdec:...]:25'

A userland script maintains the contents of the 'me6' ipset to the union of the addresses assigned to interfaces I want redirected; it's all a big mess, because this machine is both a router and an endpoint with services.  In any case, that script is:

#!/bin/sh

(ip -o -6 a s dev usb0; ip -o -6 mon addr dev usb0) |
  awk 'function ssfx(ip) { return gensub(/^([^\/]*)\/.*$/, "\\1", 1, ip) } /^[[:digit:]]+:.*inet6/{ print "ipset -! add me6 " ssfx($4) } /^Deleted.*inet6/{ print "ipset -! del me6 " ssfx($5) }' |
  sh

The more usual way that this is done, with "iptables -t nat -A PREROUTING -i $IFACE ... -j DNAT ..." doesn't work if we expect to route across $IFACE to other machines and don't wish to intercept traffic: PREROUTING happens entirely before the local routing decision, so we're looking at packets both intended for us and intended to route across us, and have no easy way of distinguishing; thus, the ipset and script.  A similar stunt would, I think, be necessary with ipv4 in a similarly complex situation, but it just happens not to arise as often, AFAICT.
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=500#comment3339



More information about the lede-bugs mailing list