Equivalent settings to "IPv6 Passthrough"?`

I have a TP-Link Archer C7 v2.0, the Japanese version. I have been using it with factory firmware until I recently switched to OpenWRT.

Lately, before switching to OpenWRT, I switched ISPs. My new ISP has native IPv6 support. It didn't work out of the box, however; I needed to upgrade my factory firmware. The 2017-01-05 update contained the following changes: "Added IPv6 Passthough function." This was the key to get IPv6 to work.
(For reference: https://www.tp-link.com/jp/support/download/archer-c7/v2/#Firmware )

Now I have switched to OpenWRT, and while a general improvement, IPv6 doesn't work anymore.

I'm able to use IPv6 if I ssh to the router and access IPv6-only services from there:

root@mon:~# ping6 ipv6.google.com
PING ipv6.google.com (2404:6800:4004:806::200e): 56 data bytes
64 bytes from 2404:6800:4004:806::200e: seq=0 ttl=55 time=3.487 ms
64 bytes from 2404:6800:4004:806::200e: seq=1 ttl=55 time=3.459 ms
--- ipv6.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.459/3.473/3.487 ms
root@mon:~# curl -6 ifconfig.co

The web interface confirms that my address is IPv6: 2404:7a80:9621:7100:1aa6:f7ff:fe8d:c0d4/64.

However, no IPv6 tests such as https://ipv6-test.com/ work when accessed from my browser, connected via the router.

According to my ISP, I should use the "passthrough" mode to get IPv6 address. OpenWRT doesn't seem to provide directly such a connection mode / protocol.

Am I able to enable the same effect as the "passthrough" mode by some combination of configuration settings in OpenWRT? What does it actually mean to be in "passthrough" mode in sense of the underlying protocols and routings?

I still want to add that I briefly tried to switching the IPv6 protocol to DHCPv6 and setting everything to "relay", according to "Example configuration section for relaying" in https://openwrt.org/docs/guide-user/network/ipv6/start, but without success.

I read it's popular in Japan to provide a /64 on-link prefix instead of using prefix delegation (which is the preferred and recommended way). The /64 on-link prefix is the reason the WAN interface has IPv6 addresses that work.

Have you tried using relays for IPv6?

I have tried to relaying DHCPv6, RA and NDP, without success. I also feel that I lack the conceptual understanding to get what's wrong and how it should work.

What do you mean by "providing a /64 on-link prefix"?

If it helps, I can try to describe my topology: a light fibre modem is connected to NTT's network who is the network operator. I connect that to my router, and use PPPoE (IPv4) for the WAN port in the router to connect to my ISP over NTT's network. My other devices connect to the router.

I don't know how I am supposed to connect with IPv6, except for using the "Passthrough" setting I have no idea how it works, but it used to work.

There are various ways for IPv6 connectivity, e.g. some are

  • dual-stack
  • DHCPv6 via SLAAC (prefix delegation)
  • stateful DHCPv6

and commonly the ISP would inform their subscriber about the implemented method to enable the subscriber for proper configuration of CPE.

It seems that some router OS have implemented IPv6 WAN options:

  • Disabled
  • Native
  • Static
  • Passthrough
  • FLET's Service
  • Tunnels 6to4
  • 6in4
  • 6rd

A bit of search in the public domain for ntt IPv6 Passthough turned up [1]

■ Customers using an off-the-shelf broadband router▼

IPv6 pass-through or IPv6 bridge functionality must be enabled.
For details on functions and settings instructions of your router, please contact the manufacturer of the router.

As far I as understand there is no such implementation in OpenWrt. It would probably require the LAN segment to be bridged with WAN, but who wants to do that?

On the other hand perhaps NAT6: IPv6 Masquerading [2] might be the solution and counts as IPv6 pass-through?

network doesn't support subnetting or prefix delegation

[1] https://asahi-net.jp/en/support/guide/ipv6/
[2] https://oldwiki.archive.openwrt.org/doc/howto/ipv6.nat6

So, it seems that Passthrough means that the router functions as a bridge and passes IPv6 packets through without routing at all, and the uplink router communicates directly to whoever answers those packets. What sounds weird to me is that if packets are going unrouted, is the router sending them just to every connected device? Is that only the phase where there isn't assigned IPv6 addresses yet and the protocols used are using broadcasting?

Anyway, NAT sounds like a sensible way to fix the situation. But ideally, my ISP should provide a better protocol for address assigment, right?

I tried to follow the linked NAT6 tutorial. I got the settings done, but no avail. Trying to run the firewall script manually shows:

root@mon:~# /etc/firewall.d/with_reload/90-nat6.fw
nat6: Firewall config="cfg02dc81" zone="lan" zone_masq6="0".
nat6: Firewall config="cfg03dc81" zone="wan" zone_masq6="1".
nat6: Found firewall zone_name="wan" with zone_masq6="1" zone_masq6_privacy="1".
nat6: Setting up masquerading nat6 for zone_name="wan" with zone_masq6_privacy="1"
nat6: Ensuring ip6tables chain="zone_wan_postrouting" contains our MASQUERADE.
ip6tables: No chain/target/match by that name.

I don't know enough about netfilter and ip6tables to make sense what's wrong, so any pointers would be appreciated. Meanwhile, I think I'm trying to read and understand the script and study more.

Ok, I got one step further. I've got zone_wan_postrouting in iptables, but ip6tables is indeed lacking that custom chain. I think it's firewall3's responsibility to set it up, but I'm not sure how I should change the configuration to make it do so.

It is definitely an odd way NTT has implemented IPv6 and as much is voiced in various places in the public domain.
Maybe it is economically motivated for generating an extra revenue stream since it was mentioned somewhere that with a landline subscription comes a /56 prefix delegation...

IPv6 contains routing information in its header. If bridged - that if it is for IPv6 only - only unsolicited IPv6 traffic from the WAN would be flushed to all all clients that is allowed to pass through the WAN firewall
Else, it would be connection tracked - and since the clients should have an IPv6 with the bridge scenario.
The problem is to bridge only IPv6 but not IPv4 - which would doable with VLAN but such does not seem to be offered by the ISP.
Anyway, personally I would prefer not to bridge WAN with LAN segments since it renders the bridged LAN segment layout transparent to the ISP.

Have you got kmod-ipt-nat6 and kmod-nf-nat6 installed?

Thanks for the pointer. I have both installed. I wonder if I'm missing some command that would re-create the config, or then there's something missing in the config itself. Here's the config:

root@mon:~# cat /etc/config/firewall

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option masq6 '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'
(skipping various "allow protocol" directives)

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

config redirect
	option dest_port '22'
	option src 'wan'
	option name 'SSH → poi'
	option src_dport '22'
	option target 'DNAT'
	option dest_ip ''
	option dest 'lan'
	option proto 'tcp udp'

All right, another step forward: found out about fw3 reload.

root@mon:~# fw3 reload
Warning: Unable to locate ipset utility, disabling ipset support
Warning: Option @zone[1].masq6 is unknown
 * Clearing IPv4 filter table
 * Clearing IPv4 nat table
 * Clearing IPv4 mangle table
 * Populating IPv4 filter table
   * Rule 'Allow-DHCP-Renew'
   * Rule 'Allow-Ping'
   * Rule 'Allow-IGMP'
   * Rule 'Allow-IPSec-ESP'
   * Rule 'Allow-ISAKMP'
   * Redirect 'SSH → poi'
   * Forward 'lan' -> 'wan'
   * Zone 'lan'
   * Zone 'wan'
 * Populating IPv4 nat table
   * Redirect 'SSH → poi'
   * Zone 'lan'
   * Zone 'wan'
 * Populating IPv4 mangle table
   * Zone 'lan'
   * Zone 'wan'
 * Clearing IPv6 filter table
 * Clearing IPv6 nat table
 * Clearing IPv6 mangle table
 * Populating IPv6 filter table
   * Rule 'Allow-DHCPv6'
   * Rule 'Allow-MLD'
   * Rule 'Allow-ICMPv6-Input'
   * Rule 'Allow-IPSec-ESP'
   * Rule 'Allow-ISAKMP'
   * Forward 'lan' -> 'wan'
   * Zone 'lan'
   * Zone 'wan'
 * Populating IPv6 nat table
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
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'
   * Zone 'lan'
   * Zone 'wan'
 * Populating IPv6 mangle table
   * Zone 'lan'
   * Zone 'wan'
 * Set tcp_ecn to off
 * Set tcp_syncookies to on
 * Set tcp_window_scaling to on

The warning Warning: Option @zone[1].masq6 is unknown and the warnings under * Populating IPv6 nat table seem to be very relevant to this case.

Okay, something about this tutorial https://oldwiki.archive.openwrt.org/doc/howto/ipv6.nat6 is weird. It mentions the option masq6, but even grepping through the whole history of the Git repo of firewall3 ( https://git.openwrt.org/project/firewall3.git ), there is not a single match of option masq6. Unless the available options are extended by kmod-ipt-nat6 or kmod-nf-nat6, such option shouldn't exist.

It seems that firewall3's support for IPv6 NAT table is less than splendid: https://bugs.openwrt.org/index.php?do=details&task_id=500&order=id&sort=desc

That is strange, the other tutorial link [2] being probably legacy but even the current [3] leverages the syntax masq6='1'

uci set $(uci show firewall | sed -n -e "/\.name='wan'$/s//.masq6='1'/p" | sed -n -e "1p")

kmod-ipt-nat6 or kmod-nf-nat6 should be loaded upon installation but might not have, perhaps check with lsmod | grep nat6. Maybe rebooting the router helps?

[3] https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

That exact query doesn't show any results, but at least modules called ip6table_nat and nf_nat_ipv6 are loaded:

root@mon:~# lsmod | grep -E 'ipv?6'
ip6_tables             10464 18 ip6table_nat,ip6table_mangle,ip6table_filter
ip6t_MASQUERADE          512  0
ip6t_NPT                1536  0
ip6t_REJECT              992  2
ip6table_filter          608  1
ip6table_mangle         1184  1
ip6table_nat             672  0
nf_conntrack           60288 15 ipt_MASQUERADE,xt_state,xt_nat,xt_conntrack,xt_REDIRECT,xt_CT,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_nat_ipv4,nf_flow_table,nf_conntrack_rtcache,nf_conntrack_ipv6,nf_nat_ipv6,nf_nat_masquerade_ipv6,nf_nat
nf_conntrack_ipv6       5424  7
nf_defrag_ipv6          4704  1 nf_conntrack_ipv6
nf_log_common           2592  2 nf_log_ipv4,nf_log_ipv6
nf_log_ipv6             4000  0
nf_nat                 10032  6 xt_nat,nf_nat_redirect,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat_ipv6,nf_nat_masquerade_ipv6
nf_nat_ipv6             4240  1 ip6table_nat
nf_nat_masquerade_ipv6    1840  1 ip6t_MASQUERADE
nf_reject_ipv6          2432  1 ip6t_REJECT
x_tables               12656 26 ipt_REJECT,ipt_MASQUERADE,xt_time,xt_tcpudp,xt_state,xt_nat,xt_multiport,xt_mark,xt_mac,xt_limit,xt_conntrack,xt_comment,xt_TCPMSS,xt_REDIRECT,xt_LOG,xt_FLOWOFFLOAD,xt_CT,iptable_mangle,iptable_filter,ip_tables,ip6t_NPT,ip6t_MASQUERADE,ip6table_mangle,ip6table_filter,ip6_tables,ip6t_REJECT

New URL see above.

1 Like

Afraid that is the end of the road for my input on subject, I am not familiar with the intricacies of NAT6... and then with the aforementioned unresolved bug...

Big thanks for following up this far! I'll post here if I learn something new.

1 Like

There seems to be 5 years old thread in Github (about adding GUI option for masq6) that indicates that the patches for adding masq6 option were shot down: https://github.com/openwrt/luci/pull/381

Here's the patch set: https://openwrt-devel.openwrt.narkive.com/AkOZ84sM/patch-0-2-firewall3-add-support-for-ipv6-nat-i-e-masquerading

The search functionality doesn't seem to work (HTTP 400), so I haven't found any related discussion.

Also, the official mailing list archive has links only to stuff newer than year 2016, and this seems to be from July 2015. I wonder what the current situation is, and are there any accessible mailing list archives? It seems from the looks of it that firewall3 doesn't have the necessary functionality for setting up IPv6 NAT.

It should be possible to set up with iptables directly.

Reading this thread

pointing to the same bug plus the absence of masq6 from the FW3 source code would imply that it is indeed not implemented and requires a custom script/rule.

I tried to enable masquerading by adding

ip6tables -t nat -A POSTROUTING -j MASQUERADE

to /etc/firewall.user. It successfully adds the rule to iptables, but stuff's still not working. Or should I say, it worked briefly (I was able to get browser-based IPv6 tests working) but after rebooting the router, it stopped working again.

I'm now trying to troubleshoot, but I don't know what to do. It says on the interfaces page of the GUI that the LAN interface IPv6 address is fd26:e9f1:e833::1. I'm able to ping6 and traceroute6 that address from my computer. Vice versa for pinging my computer fd26:e9f1:e833::a074:2e95:b44e:82bb (seems to be an address from the ULA range) from router. However, I'm not able to ping non-local addresses (tried with 2404:6800:4004:80e::200e which is from ipv6.google.com) from my computer, but traceroute6 says that at least it hops to the router, so the computer's routing table is okay, I guess.

How should I go troubleshooting this?