[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