OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version lede-17.01
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Joseph C. Sible - 12.02.2017

FS#500 - firewall3: missing targets with IPv6 NAT

When the kmod-ipt-nat6 package is installed, running /etc/init.d/firewall reload or /etc/init.d/firewall restart produces warnings that targets are missing:

 * Populating IPv6 nat table
   * Zone 'lan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
   * Zone 'wan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'

I tested this on an Archer C7 v2 running LEDE 17.01.0rc2.

Hannu Nyman commented on 12.02.2017 18:55

I think that the firewall fw3 only defines & creates those prerouting/postrouting chains for ipv4, and then later some other part of the firewall (zone rules creation?) finds also the ipv6 NAT table (due to nat6 being installed) and tries to attach similar rules to it as for the ipv4 NAT table, but it fails due to the missing chains.

I think that the definition of the pre/postrouting chains for only ipv4 "family" can be seen from:

https://git.lede-project.org/?p=project/firewall3.git;a=blob;f=zones.c;hb=HEAD#l26

https://git.lede-project.org/?p=project/firewall3.git;a=blob;f=defaults.c;hb=HEAD#l25

IPv6 NAT being installed is so rare, that it seems to expose a bug in the firewall code.

Edward M. commented on 30.06.2017 13:56

Let's solve this problem, NAT is a fundamental feature!

I had a look at the executed IPv4 iptables nat commands (fw3 -4 print | grep " nat ") and re-executed those as ip6tables commands.

For this purpose, I have changed /etc/init.d/firewall so that the targets above are existent before the rules are applied. Unhappily it didn't solve the problem!

I created the targets, but it seems they couldn't found:

 * Populating IPv6 nat table
   * Zone 'lan'
Warning: ip6tc_append_entry(): No chain/target/match by that name
Warning: ip6tc_append_entry(): No chain/target/match by that name
   * Zone 'wan'
Warning: ip6tc_append_entry(): No chain/target/match by that name
Warning: ip6tc_append_entry(): No chain/target/match by that name

instead of:

 * Populating IPv6 nat table
   * Zone 'lan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
   * Zone 'wan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'

Executed after flushing and before re-starting fw3:

ip6tables -t nat -N prerouting_rule
ip6tables -t nat -N postrouting_rule

ip6tables -t nat -N zone_lan_postrouting
ip6tables -t nat -N zone_lan_prerouting
ip6tables -t nat -N prerouting_lan_rule
ip6tables -t nat -N postrouting_lan_rule
ip6tables -t nat -A zone_lan_prerouting -m comment --comment "!fw3: user chain for prerouting" -j prerouting_lan_rule
ip6tables -t nat -A zone_lan_postrouting -m comment --comment "!fw3: user chain for postrouting" -j postrouting_lan_rule

ip6tables -t nat -N zone_wan_postrouting
ip6tables -t nat -N zone_wan_prerouting
ip6tables -t nat -N prerouting_wan_rule
ip6tables -t nat -N postrouting_wan_rule
ip6tables -t nat -A zone_wan_prerouting -m comment --comment "!fw3: user chain for prerouting" -j prerouting_wan_rule
ip6tables -t nat -A zone_wan_postrouting -m comment --comment "!fw3: user chain for postrouting" -j postrouting_wan_rule

I found https://github.com/akatrevorjay/openwrt-masq6, but I'm not sure about ULA prefix (-s "$ula_prefix"). Is this parameter mandatory?

Nathaniel Wesley Filardo commented on 26.08.2017 09:42

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 mon addr dev usb0 & ip -o -6 a s dev usb0 ; wait) |
  awk 'function ssfx(ip) { return gensub(/^([^\/]*)\/.*$/, "\\1", 1, ip) } /^[[:digit:]]+:.*global/{ print "ipset -! add me6 " ssfx($4) } /^Deleted.*global/{ 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.

Vladislav Grigoryev commented on 26.04.2019 10:39

The issue is valid for OpenWrt 18.06.

Use cases:

  • DNS6 traffic interception for DNS hijacking.
  • TCP6 and DNS6 traffic interception for Tor client.
  • IPv6 masquerading for dual-stack setup with no prefix, e.g. VPNs, VPSs, some ISPs, etc.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing