IPv6 Bridging Not Working on Google WiFi (OpenWRT 24.10.4)

stepheni · October 27, 2025, 9:25am

Hi folks,

I need some assistance getting IPv6 working correctly on a Google WiFi (Gale) device running OpenWRT 24.10, recently upgraded to 24.10.4.

Scenario:

The Gale device is being used as a wireless bridge to a POP router located behind a brick and then concrete wall. Both IPv4 and IPv6 need to operate on the same subnet as the POP router due to the requirements of some communications hardware that the IP is being supplied to. In other words, full IPv4 and IPv6 bridging is required — over Wi-Fi, exiting via the gigabit Ethernet port.

Current status:

IPv4 bridging: Works perfectly.
IPv6 bridging: IP supplied perfectly; Routing of data fails — traffic appears to stop at the br-lan interface and doesn’t pass.

If clients are supplied the POP Router's Global Unicast IP address as the Gateway - manually - then all works fine. This is not satisfactory.

I’ve included the standard setup steps (auto-generated via Google’s AI for clarity) below this post.

Can anyone please share a set of working steps or configuration example or some tips that will work in order to to get IPv6 bridging functioning properly?

Thanks

Steve I

............................
[ Example provided. All steps tested. Note that this is provided for simplicity and clarity ]

Preparation

Install OpenWrt: Flash OpenWrt onto a compatible router.
Connect and log in: Connect your computer to the OpenWrt router via one of its LAN ports.
Set a static IP: Change the OpenWrt router's LAN IP address to a static address on a different subnet from your Google WiFi network. In our examples we leave it as the default 192.168.1.0/24 as the POP Router uses 192.168.0.0/24.
Install relayd: Use SSH or the web interface (LuCI) to install the luci-proto-relay package, which is the graphical interface for relayd.

sh

opkg update
opkg install luci-proto-relay

Step 1: Connect OpenWrt Google WiFi to PoP WiFi Adapter

Go to Network > Wireless in the LuCI web interface.
Click Scan on the radio you want to use. Note that the the 5 GHz radio is used on the POP router for a faster connection.
Find your POP WiFI network in the list and click Join Network.
Enter the password for your POP network.
Set the new interface's name to wwan; Set the firewall zone is set to wan.
Click Submit, then Save & Apply.

Step 2: Configure the IPv4 relayd bridge

Go to Network > Interfaces.
Click Add new interface.
Name the new interface repeater_bridge.
Choose Relay bridge as the protocol.
Select lan and wwan to be bridged together in the "Relay between networks" field.
Click Save, then Save & Apply.

Step 3: Disable DHCP on the OpenWrt Google WiFi device

Go to Network > Interfaces.
Click Edit on your lan interface.
Go to the DHCP Server tab and the General Setup sub-tab.
Check the Ignore interface box to disable the DHCP server.
Click Save, then Save & Apply.

Step 4: Add IPv6 relay

Go to Network > Interfaces.
Click Edit on your lan interface.
Under the DHCP Server tab, go to IPv6 Settings.
Change the following settings to "relay mode":

RA-Service: relay mode
NDP-Proxy: relay mode

Set DHCPv6-Service to disabled.
Click Save.
Edit the wwan interface (created in Step 1).
Go to the DHCP Server tab and IPv6 Settings sub-tab.
Set Designated master to checked.
Set both RA-Service and NDP-Proxy to relay mode.
Set DHCPv6-Service to disabled.
Click Save, then Save & Apply to restart the network.

brada4 · October 27, 2025, 10:33am

Does your PooP router support GRE?

mk24 · October 27, 2025, 10:58am

I think you need a separate wwan6 interface to acquire an IPv6 address for the link (a single interface cannot run dhcp and dhcpv6 at the same time, since the configuration system makes that an either / or choice). Use protocol dhcpv6 and device @wwan. This is like the wan and wan6 in default configurations.

Use ifstatus wwan6 to confirm an IP obtained.

stepheni · October 27, 2025, 11:13am

GRE should work if the appropriate packages are installed.

However, that’s not the main point here — simplicity is.

The commonly available instructions don’t seem to work as expected. So, is the issue with the instructions themselves, or is it something deeper that warrants broader investigation?

We can either publish clearer, verified instructions—making them discoverable through search/AI systems — or identify and fix any underlying software issues.

Either way, everyone benefits.

stepheni · October 27, 2025, 11:15am

We have been down this path repeatedly. The same issue arises at the "lan" interface.

stepheni · October 27, 2025, 11:34am

[ Sorry pressed ENTER too fast. ]

The wwan6 the interface is receiving all IPv6 assignments that we would expect it to receive.

Those of us working on this also expected and have heavily researched utilization of a wwan6 interface associated with the DHCPv6 Client ...

But it does not appear in MOST Web-accessible guides.

Interfaces at the end-points are also receiving all addresses that we expect them to receive - even without the wwan6 interface under the "common" instructions that we have attached.

brada4 · October 28, 2025, 12:38am

Ok, enable GRETAP and it will encapsulate full ethernet in wifi ( dont forget to save parameter at least 5x to make chadbod h-appy)

Please connect to your OpenWrt devices using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

mk24 · October 28, 2025, 12:51pm

I don't know. You need to investigate beyond "it doesn't work." I use v6 relay a lot both with LTE connections and wifi uplinks to other networks, and it does work.

One thing I would add to instructions is to remove ULA prefix, as ULAs are not needed in a simple home network. They just cause confusion if not being used for any local access.

Things to investigate:

Does the wan6 have a GUA address, and is it /64?
The lan will not have a GUA, but it works without it. The LAN's LLA is the LAN endpoints' gateway.
Each endpoint should have configured a GUA in the same /64 as the wan, and the default route and DNS should be the router's LLA.
There will be a /128 route to each LAN endpoint after it chooses a SLAAC IP. This is done by the router snooping the NDP packets when the endpoint does Duplicate Address Detection.

stepheni · October 28, 2025, 1:04pm

Here are the files as Requested from the BASE SET of instructions posted at the start (that were generated "with assistance")..

Note: It is known and recognised that there is an issue with these instructions - instructions that are found "as standard" through most regular queries out there.

It is recognised that there is no interface i.e. wwan6 defined that is set up as a DHCPv6 Client. It is also recognised that this interface should be associated with the lan (br_lan) interface.

The configuration as "extended" (to the files provided below) will slow IPv6 addresses down to clients ok - biut one CANNOT use the addresses provided to get outside of the OpenWRT loadeddevice. Note that this issue appears not to be just listed to teh Google WiFi "Gale" device that this is developed on.

Here are the "base" files as asked for:

Command: ubus call system board

{
"kernel": "6.6.110",
"hostname": "OpenWrt-Gale",
"system": "ARMv7 Processor rev 5 (v7l)",
"model": "Google WiFi (Gale)",
"board_name": "google,wifi",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.4",
"revision": "r28959-29397011cc",
"target": "ipq40xx/chromium",
"description": "OpenWrt 24.10.4 r28959-29397011cc",
"builddate": "1760891865"
}
}

File: /etc/config/network

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd8b:c3de:623a::/48'
option packet_steering '1'

config device
option name 'br-lan'
option type 'bridge'
list ports 'lan'

config device
option name 'lan'
option macaddr '00:00:00:85:49:67'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config device
option name 'wan'
option macaddr '00:00:00:85:49:66'

config interface 'wan'
option device 'wan'
option proto 'dhcp'

config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'

config interface 'wwan'
option proto 'dhcp'

config interface 'repeater_bridge'
option proto 'relay'
list network 'lan'
list network 'wwan'

File: /etc/config/wireless

config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/a000000.wifi'
option band '2g'
option channel '1'
option htmode 'VHT20'
option disabled '1'

config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/a800000.wifi'
option band '5g'
option channel '104'
option htmode 'VHT80'
option cell_density '0'

config wifi-iface 'wifinet0'
option device 'radio1'
option mode 'sta'
option network 'wwan lan'
option ssid 'XXXXXXXXXX'
option encryption 'psk2'
option key 'XxXxXxXx'

File: /etc/config/dhcp

config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
option filter_aaaa '0'
option filter_a '0'

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ra 'relay'
option ignore '1'
option ndp 'relay'
option preferred_lifetime '7d'

config dhcp 'wan'
option interface 'wan'
option ignore '1'

config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
option piofolder '/tmp/odhcpd-piofolder'

config dhcp 'wwan'
option interface 'wwan'
option ignore '1'
option master '1'
option ra 'relay'
option ndp 'relay'
option preferred_lifetime '7d'

File: /etc/config/firewall

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

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

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

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'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

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

stepheni · October 28, 2025, 1:19pm

Part of what I am trying to tease out here is a "swiss army knife" set of instructions that are simple and that work - so that the extensive misguidance provided by AI engnes etc. in the future is avoided. i.e. we can supply the results to these "sources" and "fix what is broke".

Bridging to the same Internet-domain-space is a rather elementary ask; one CANNOT easily obtain Gigabit-ethernet-interfaced WiFi Dongles that work on the higher-speed WiFi bands. Therefore one needs to repurpose commonly available hardware to solve these issues.

At this point I change from "I" to a "we" as there is a team of us behind this...

As for your comments we are aware of all of this and are very grateful that you have spent the time to suggest this; in our experiments we run into brick-wall at the "lan"/"br-lan" point that has been frustrating us. We supply an IPv6 static gateway Global Unicast address and all flows PERFECTLY. That is not what we should need to do ... so either its an "anomaly" or more likely that we are doing something wrong ourselves

That's why "we" have come here

stepheni · October 29, 2025, 1:06pm

We have a (hopefully) repeatable set of steps that MAY work (and we stress the word MAY). It requires further investigation and we have to move on.

Note that the "management" interface is hidden (i.e. 192.168.1.1/24) - and that a machine must have a static IP address inside that range connected to the ethernet network to access the LuCI management pages.

Our team that has been looking into this are not 100% happy with the results; even getting here we have been locked out and have had to reflash test devices.

stepheni:

Preparation

Install OpenWrt: Flash OpenWrt onto a compatible router.

Connect and log in: Connect your computer to the OpenWrt router via one of its LAN ports.

Set a static IP: Change the OpenWrt router's LAN IP address to a static address on a different subnet from your Google WiFi network. In our examples we leave it as the default 192.168.1.0/24 as the POP Router uses 192.168.0.0/24.

Install relayd: Use SSH or the web interface (LuCI) to install the luci-proto-relay package, which is the graphical interface for relayd.

sh
opkg update
opkg install luci-proto-relay
Step 1: Connect OpenWrt Google WiFi to PoP WiFi Adapter

Go to Network > Wireless in the LuCI web interface.

Click Scan on the radio you want to use. Note that the the 5 GHz radio is used on the POP router for a faster connection.3.

Find your POP WiFI network in the list and click Join Network.5.

Enter the password for your POP network.7. 8.

Set the new interface's name to wwan; Set the firewall zone is set to wan.

Click Submit, then Save & Apply.

Step 2: Configure the IPv4 relayd bridge

Go to Network > Interfaces.

Click Add new interface.

Name the new interface repeater_bridge.

Choose Relay bridge as the protocol.

Select lan and wwan to be bridged together in the "Relay between networks" field.

Click Save, then Save & Apply.

Step 3: Disable DHCP on the OpenWrt Google WiFi device

Go to Network > Interfaces.

Click Edit on your lan interface.

Go to the DHCP Server tab and the General Setup sub-tab.

Check the Ignore interface box to disable the DHCP server.

Click Save, then Save & Apply.

Step 4: Add IPv6 relay

Go to Network > Interfaces.

Click Edit on your lan interface.

Under the DHCP Server tab, go to IPv6 Settings.

Change the following settings to "relay mode":

RA-Service: relay mode

NDP-Proxy: relay mode

Set DHCPv6-Service to disabled.

Click Save.

Edit the wwan interface (created in Step 1).

Go to the DHCP Server tab and IPv6 Settings sub-tab.

Set Designated master to checked.

Set both RA-Service and NDP-Proxy to relay mode.

Set DHCPv6-Service to disabled.

Click Save, then Save & Apply to restart the network.

Step 5: Connect OpenWrt Google WiFi to PoP WiFi Adapter as a DHCPv6 Client

Go to Network > Wireless in the LuCI web interface.
Click Add new interface
Enter wwan6 as the interface name.
Set Protocol to DHCPv6 Client
Click Create Interface. This takes you to a configuration screen where some action is necessary.
At Device select your wireless network client that you connected to in Step 1. In the case of our example it is Wireless Network Client "TestNetwork-5G" (wwan)
Set Request IPv6-address to Force
In our case we have to set 64-bit prefixes. Under Request IPv6-prefix select 64. Note that the Automatic option may suit most applications.
Click Save, then Save & Apply to restart the network.

Step 6: Assign your new "wwan6" interface to the correct firewall zone

Go to Network > Wireless in the LuCI web interface.
Locate the WAN interface that you created in Step 5 (i.e. wwan6) and click Edit
Select the Firewall Settings tab
In Create/Assign firewall-zone select wan
Click Save, then Save & Apply .

Reboot the Device.

At this point things started to work (repeatedly) and without necessity to reload firmware from scratch.

What does not make sense is the IPv6 settings in Step 4 - especially 4.9 . Yet it produced results that we wanted.

We may have missed something here. Please advise if this is the case.

stepheni · October 30, 2025, 10:23am

Mk24,

Thanks for responding. All points you raise are exceptionally good points from a hardening perspective and will be considered fully when we have time to look at this further.

Meanwhile we have a functioning - imperfect - solution; all that we have added is necessary spanning-tree protection.

If it ain’t broke - don’t fix as they say …

Everything that we tried at some stage “broke” and locked us out requiring REPEATED firmware re-flash procedure (Even with SuzyQ cables available and the security-screw known about).

The “Interim” solution has been provided to “major engines” to ponder.

Regards and Thanks

Steve I

system · November 9, 2025, 10:24am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.