Two wireguard VPNs used to work now goes haywire

Wez · May 16, 2026, 7:58pm

So I used to run 2 proton VPN wireguard tunnels on my router, one for guests and one for our smartphones to throw a pebble into app's tracking nonsense. I would add the first ProtonVPN wireguard interface and set up. Then add a second and during importing the second config I would change it's IP address from 10.2.0.2/32 to something like 10.2.0.4/32 because I think I used to have issues if I did not change the IP. Then I would use pbr and firewall zones to adequately pipe the right networks out of the right wireguard. But now I do this and use my temporary pbr rule that forces my PC to use a wireguard interface and if I do a speedtest from the initial wireguard, everything is fine. If I connect myself to the second wireguard and run a speedtest all hell breaks loose.

I tried to paste in the log but apparently it is way too long but there's lots of this kind of thing:

[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469757] ==================== FE ====================
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469774] 0x00000000: 810000b0 00000000 03000326 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469781] 0x00000010: 0000090a 00000000 00001818 000fffff
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469786] 0x00000020: 21021000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469790] 0x00000030: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469794] 0x00000040: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469798] 0x00000050: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469803] 0x00000060: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469807] 0x00000070: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.469811] 0x00000080: 00000000 00000000 00000000 00000000

and

[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471407] ==================== PPE0 ====================
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471411] 0x00002200: 0000020d 000a770e ffffffff 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471416] 0x00002210: 00000000 00000000 00000000 00114fbc
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471420] 0x00002220: 43400000 00000001 0001001e 3fff3fff
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471424] 0x00002230: 00013fff 00000000 03e80003 0001000c
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471429] 0x00002240: 00010007 00000000 00000000 000cb777
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471433] 0x00002250: 20000000 00e4e4e4 deadbeef deadbeef
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471437] 0x00002260: deadbeef deadbeef deadbeef deadbeef
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471442] 0x00002270: deadbeef deadbeef deadbeef deadbeef
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471447] 0x00002280: 00000100 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471451] 0x00002290: 00000000 00000000 00000000 00000000
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.471455] 0x000022a0: 00000000 00000000 00000000 00000000

and

[16 May 2026, 20:39:28 BST] kern.info: [ 2314.603661] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[16 May 2026, 20:39:28 BST] kern.info: [ 2314.603708] mtk_soc_eth 15100000.ethernet eth1: Link is Down
[16 May 2026, 20:39:29 BST] kern.err: [ 2315.140248] mtk_soc_eth 15100000.ethernet: warm reset failed
[16 May 2026, 20:39:29 BST] kern.info: [ 2315.160782] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/2500base-x link mode
[16 May 2026, 20:39:29 BST] kern.info: [ 2315.160945] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
[16 May 2026, 20:39:29 BST] kern.info: [ 2315.388844] mtk_soc_eth 15100000.ethernet eth1: PHY [mdio-bus:01] driver [RTL8221B-VB-CG 2.5Gbps PHY (C45)] (irq=61)
[16 May 2026, 20:39:29 BST] kern.info: [ 2315.389116] mtk_soc_eth 15100000.ethernet eth1: configuring for phy/sgmii link mode
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Network device 'eth1' link is down
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wan' has link connectivity loss
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wan6' has link connectivity loss
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wan6' is now down
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: wan (4109): udhcpc: received SIGTERM
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: wan (4109): udhcpc: unicasting a release of 82.xx.xx.xx to 80.xx.xx.xx
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: wan (4109): udhcpc: sending release
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: wan (4109): udhcpc: entering released state
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: wan (4109): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wan' is now down
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wg2' has lost the connection
[16 May 2026, 20:39:29 BST] daemon.notice: netifd: Interface 'wg_server_iot' has lost the connection
[16 May 2026, 20:39:29 BST] user.notice: pbr [10851]: Forwarding is disabled
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg_server_LAN' has lost the connection
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wireguard_0' has lost the connection
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg2' is now down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg2' is setting up now
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Network device 'wg_server_iot' link is down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Network device 'wg_server_LAN' link is down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg_server_iot' is now down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg_server_iot' is setting up now
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Network device 'wireguard_0' link is down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg_server_LAN' is now down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wg_server_LAN' is setting up now
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wireguard_0' is now down
[16 May 2026, 20:39:30 BST] daemon.notice: netifd: Interface 'wireguard_0' is setting up now
[16 May 2026, 20:39:30 BST] user.notice: ddns-scripts[5162]: xx_xx_xxxxxxxxx_com: PID '5162' terminated by 'SIGTERM' at 2026-05-16 20:39
[16 May 2026, 20:39:31 BST] daemon.notice: netifd: Interface 'wg2' is now down
[16 May 2026, 20:39:31 BST] daemon.notice: netifd: Interface 'wireguard_0' is now down
[16 May 2026, 20:39:31 BST] user.notice: pbr [10851]: Processing environment (on_interface_reload) WARNING: Uplink/WAN interface is still down, going back to boot mode.
[16 May 2026, 20:39:31 BST] user.notice: pbr [10851]: Setting trigger (on_boot) Forwarding is enabled
[16 May 2026, 20:39:31 BST] user.notice: pbr [11717]: Forwarding is disabled
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: Network device 'eth1' link is up
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: Interface 'wan' has link connectivity
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: Interface 'wan' is setting up now
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: Interface 'wan6' has link connectivity
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: Interface 'wan6' is setting up now
[16 May 2026, 20:39:32 BST] kern.info: [ 2317.922324] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: wan (12039): udhcpc: started, v1.37.0
[16 May 2026, 20:39:32 BST] daemon.notice: netifd: wan (12039): udhcpc: broadcasting discover
[16 May 2026, 20:39:32 BST] user.notice: pbr [11717]: Processing environment (on_interface_reload) WARNING: Uplink/WAN interface is still down, going back to boot mode.
[16 May 2026, 20:39:32 BST] user.notice: pbr [11717]: Setting trigger (on_boot) Forwarding is enabled
[16 May 2026, 20:39:32 BST] user.notice: pbr [12264]: Forwarding is disabled
[16 May 2026, 20:39:33 BST] user.notice: pbr [12264]: Processing environment (on_interface_reload) WARNING: Uplink/WAN interface is still down, going back to boot mode.
[16 May 2026, 20:39:33 BST] user.notice: pbr [12264]: Setting trigger (on_boot) Forwarding is enabled
[16 May 2026, 20:39:33 BST] user.notice: pbr [12779]: Forwarding is disabled
[16 May 2026, 20:39:34 BST] user.notice: pbr [12779]: Processing environment (on_interface_reload) WARNING: Uplink/WAN interface is still down, going back to boot mode.
[16 May 2026, 20:39:34 BST] user.notice: pbr [12779]: Setting trigger (on_boot) Forwarding is enabled
[16 May 2026, 20:39:34 BST] daemon.notice: netifd: wan (12039): udhcpc: broadcasting discover
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: wan (12039): udhcpc: broadcasting select for 82.xx.xx.xx, server 80.xx.xx.xx
[16 May 2026, 20:39:35 BST] user.notice: pbr [13340]: Forwarding is disabled
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: wan (12039): udhcpc: lease of 82.xx.xx.xx obtained from 80.xx.xx.xx, lease time 357304
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Interface 'wireguard_0' is setting up now
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Interface 'wg2' is setting up now
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Interface 'wan' is now up
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Interface 'wg2' is now up
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Network device 'wg2' link is up
[16 May 2026, 20:39:35 BST] user.notice: SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev eth1 ingress
[16 May 2026, 20:39:35 BST] user.notice: SQM: ERROR: cmd_wrapper: tc: LAST ERROR: Error: Cannot find specified qdisc on specified device.
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Interface 'wireguard_0' is now up
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: Network device 'wireguard_0' link is up
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: wg_server_iot (11132): Try again: `xx.xx.xxxxxx.com:xxxx'. Trying again in 1.00 seconds...
[16 May 2026, 20:39:35 BST] daemon.notice: netifd: wg_server_LAN (11184): Try again: `xx.xx.xxxxxx.com:xxxx'. Trying again in 1.00 seconds...
[16 May 2026, 20:39:36 BST] user.notice: firewall: Reloading firewall due to ifup of wan (eth1)
[16 May 2026, 20:39:36 BST] user.notice: nlbwmon: Reloading nlbwmon due to ifup of wan (eth1)

I am not sure what is going on. I am pretty sure this is the same thing I used to do. Is this a gl.inet Flint 2 hardware issue? Is it that I went from it working fine in 24.10.x but going to 25.12.4 where things go wrong? A bug? I am at a loss to figure this out.

egc · May 16, 2026, 8:33pm

Could be a driver crash

But we have to see the configs to see if that is causing something.

Are you using sqm?
Are you using harware offload?

You could try disabling those

Wez · May 16, 2026, 8:34pm

I have SQM on upload only for WAN to help bufferbloat during upload and I use SQM on the guest to ensure they can't hog the bandwidth. I have hardware offload off and I don't have it on software either because those are incompatible with SQM. Everything is quite standard, VLANs separating networks, wireless interfaces broadcasting them. One thing about my system that is odd is how I get my vlans to go across the 802.11s mesh. These are the notes I use (not sure if this would have anything to do with something so obscure as my issue in the opening post I made:

Now for the "hack" method I figured out. This is a replacement method that does NOT use vxlan. It's one or the other. Do not do both.. If you do vxlan and some of your routers are not capable of making it work fast and reliable, remove all the vxlan stuff and the bridging and everything and try this hack method instead. (Hack in the 1970s meaning, where you get something working even if unconventionally and in unexpected ways!)

So similarly to the previous mesh method, you have your backhaul interface 999 set to MTU of 1500, you have your 802.11 mesh all set up and set to use your backhaul. Now... Edit your 802.11s mesh and find in one of the advanced tabs what it's physical address is, it might be something like phy1-mesh0. Copy it and then edit your br-lan again and bridge that into the ports. It won't likely show up so you have to use the bottom custom part to paste it in and press enter. Once you do that flip over to the vlan tagging tab and Tag in all your vlans to the mesh's interface you just bridged.

On paper I thought this would work, but it turns out there is 1 final "hack" method that made the vlans actually flow over the air and make this work. Add a "GRETAP tunnel over IPv4" interface on all your routers. Don't bother configuring it, just have it there. Then reboot your routers. The vlans will magically communicate over the mesh and the system will work. I found this was more reliable for me on a lower powered router like the gl.inet Marble than trying to use vxlan. So I am including this alternative "hack" method in case it's useful.

The GRETAP interface acts as a dummy driver trigger. Even if unconfigured, its presence in the kernel seems to force the MediaTek hardware offloading to correctly process tagged frames across the 802.11s bridge that otherwise get dropped or slowed down.

But my PC is connected directly to Flint 2's LAN port and is not utilising the mesh while doing speedtest.

Is my method for adding 2 wireguard interfaces incorrect perhaps? I have 2 wireguard servers so I can get into my home network while away but that is entirely separate from this issue with the "client" wireguards that both use ProtonVPN and yes they have different imported configs, I am not trying to use the same for both.