With GL firmware this can be difficult to accomplish, because the vpn software is different and only can have 1 interface and is different than OpenWrts version of luci-proto-wireguard.
But what you can do:
is follow the guide like how mullvad shows it but then for nordvpn for peers:
And then re-create another the same vpn interface but with one different peer?
and then you can use mwan3 to track the speed and change route?
Also i have another question because you are a smart guy and i couldn't figure out on myself. I use wireguard as i said with split vpn. Some hosts go through the vpn some no. I want to use the Killswitch but just for the ones who use the VPN. Do you know a way to achieve that?
Yeah I switched back to pure OpenWRT snapshots when the op24 hit 2 months old. They said they're working on a leak problem (I assume IP leak) but they first said that weeks ago...op24 worked flawless for me and I had it installed while away for 3 weeks and it was without issue for my wife the entire time. I'll switch back (probably) if they update it. Until then I'm happily back running OpenWRT snapshots.
There seems to be a big consensus on these fora that the op24 version of the firmware has been one of the most promising and functional versions for a large number of the users on these fora and yet the developers appear to be hell-bent on not driving it into the mainstream, keeping it as beta and not even updating it in time. Another bizzare decision by this company (a router with a photoframe anyone?!).
Im also in for better support to op24, but i also get why they keep building on the mtk sdk there are just some issues which aren't fixed yet on mt76, if you happen to have a device in your network which enable the vulnerability this driver expose, you will get into a crash course for this the mtk sdk works better, it can be very traffic or device specific for this to happen, 886, 881
But i also understand developing from the op24 branch means you are still managing on OpenWrt snapshots with a high volatility of kernel changes, sometimes such change can go negative ive seen that with the mvbu platform for example that the switch started sending vlans inversed towards the isp, it requires much more checking and safeguarding the code, there might also be highly experimental changes to it aswell in OpenWrts code base.
Also i believe atleast for the package pbr it got rid by the pbr-iptables packages, so in my eyes it looks that they are hinting to delete iptables to nftables interpreters soon, alot of the vpn policies in the GL ui still use iptables and also ipsets rather than nftsets, there will be alot of challenges and they may need eventually to rewrite the vpn policies, i think they also said this.
Also OpenWrt plan to ditch the update manager opkg for APK from Alpine Linux its now a experimental option which can be checked upon compiling, but they will plan to ditch opkg.
So its just alot of refactoring, changing i think that is what give them a hold up , one moment it looks easy the other moment it may bring in other questions, for a company perspective that might be too risky to do.
So understandable they look at op24 at a lower phase, but i'd hope they release a newer one with some newer updates to mt76
Yep...Flashed to it a couple of hours ago...Up and running fine so far as was the last build.
Came at an opportune time...I had just flashed today's latest OpenWRT snapshot which bricked the router...So rather than reflashing my saved OWRT build I took the opportunity to reflash back to OP24 and restored settings...Then flashed today's OP24 4.63..All good.
Anyone else notice a drop in 5GHz range as soon as they upgraded to 4.6.3-op24? I live in two-story house and using 4.6.0-op24 was able to get good 5GHz speed from upstairs. No other change after upgrading and my devices are all bumping down to 2.4GHz aggressively as soon as I head upstairs. Unfortunately I can't find a way to download the image of 4.6.0-op24 anymore.
I have been using 4.6.3-op24 on beryl ax without any issue. Updated to 4.6.4-op24, have issues where repeater is not able to get IP address assigned from source network. Tried few things like forgetting network and restarting didn't help. As soon as I rolled it back to 4.6.3-op24 started working without any issues.
, one moment it looks easy the other moment it may bring in other questions, for a company perspective that might be too risky to do.