Gargoyle 1.15.x OpenWrt 24.10 beta - 2026-01-06

[ispyisail]

No, I have both running alongside each other and have for years.
If you are trying to route the same client subnets from both OpenVPN and WireGuard though, that would be a disaster.

Highly likley, its crashes in a big way

[Lantis]

Hi Lantis,

I've been struggling with BETA - 2025-10-24 for quite a while trying to setup a wireguard server on my ASRock G10.
While my wireguard setup worked perfectly fine with openwrt 23.05 codebase, it fails with latest 24.10 builds. In fact, with 24.10-based builds, wireguard client can successfully connect to the router IP (I can properly browse gargoyle UI from my client). However, the client fails to connect to the WAN or to any other host on the LAN (no http, no ssh, no ping).
Nailing down the issue, it appears that the packets stop being routed to the WAN & LAN as soon as I turn on "Enforce DHCP assignments" and assign at least one static address.
I was able to reproduce this weird behavior on both a NetGear WNDR3700v4 and an ASRock G10. The behavior is same with 2025-10-24 and 2026-01-06 builds.
Indeed, the very same setup works perfectly, allowing smooth connection to both WAN & LAN, if I revert back to any 23.05 build (e.g. 2024-11-13) on any of the two routers.
I think openVPN shows same issue, even though I haven't had time to nail it down so clearly.
Cheers.

Thanks for the feedback!
I'll need to look more closely at that one and figure out how to keep it working.
The rule isn't supposed to interfere, in theory it works like this:
- If your IP or MAC is not known to us, skip the next 2 rules
- If your IP is known and your MAC doesn't match, reject
- If your MAC is known and your IP doesn't match, reject
- Accept

So WireGuard (+OpenVPN) clients should be bypassing at that first rule, but clearly something is amiss.

It probably worked fine on the earlier versions because that Enforce DHCP Assignments function was pretty much broken

So for now leave it off if you can and I'll take a look. If I've got something to test I'll send you a PM

I've put in a fix for this, I'll release some new builds in the next week which hopefully solve this.
This is one of those weird changes between iptables and nftables and they behave unexpectedly differently when it comes to these rules. Looks like in the old rules they were being skipped entirely, not jumping out because they didn't match. Now in the new rules they are explicitly treated as unmatching which rejects the packet.

Anyway, worth a try. Keep an eye out.

The first issue was importing the configuration. I ended up setting it up manually, which unfortunately caused a network outage. The kids were not impressed, so I need to set up a proper test environment before trying again.

I haven’t done the necessary due diligence yet.

I've put in a fix for config importing. Doesn't change the fact that you can't route the same subnet from two places at once but it should get you closer to a result.

[boldga]

Could you please add support for ASUS TUF-AX4200Q? OpenWrt 24.10.5 has added support for this device, which features an additional 2.5G port compared to the TUF-AX4200.

[fred38]

Lantis wrote:
I've put in a fix for this, I'll release some new builds in the next week which hopefully solve this.
This is one of those weird changes between iptables and nftables and they behave unexpectedly differently when it comes to these rules. Looks like in the old rules they were being skipped entirely, not jumping out because they didn't match. Now in the new rules they are explicitly treated as unmatching which rejects the packet.

Anyway, worth a try. Keep an eye out.

Sounds great ! I'll stay tuned

By the way, I noticed another unrelated issue, with wifi hwmode:
Using the latest 2025-01-06 build (didn't check with older builds), on my ASRock G10, when I select A+N for 5GHz Operating Mode (instead of A+N+AC), with "40MHz 2nd above channel", "htmode: HT40+" gets properly written in /etc/config/wireless, which is perfectly fine. Also, the radio is correctly operating with 40MHz bandwidth.
Unfortunaly, this HT40+ htmode is not properly understood by gargoyle UI when reopening the "Connection->Basic" page. In fact, it shows the "5GHz Operation Mode" as "disabled". This can be quite misleading... Also, if I want to change anything elsewhere in this "Basic" page, forgetting to re-specify all my wifi settings, then the radio finally gets disabled...
You may wonder why I want to disable AC. This is because my other router (WNDR3700v3) which I use as 2nd AP is limited to wifi N and I noticed that fast roaming is better when both AP's share the same operating mode.

[ispyisail]

Question, is there a build for the Flint2?

[pythonic]

is there a build for the Flint2?

yes: gl-mt6000 in mediatek/filogic

[Lantis]

Could you please add support for ASUS TUF-AX4200Q? OpenWrt 24.10.5 has added support for this device, which features an additional 2.5G port compared to the TUF-AX4200.

Sure, it will be included in the new build this week.

By the way, I noticed another unrelated issue, with wifi hwmode:
Using the latest 2025-01-06 build (didn't check with older builds), on my ASRock G10, when I select A+N for 5GHz Operating Mode (instead of A+N+AC), with "40MHz 2nd above channel", "htmode: HT40+" gets properly written in /etc/config/wireless, which is perfectly fine. Also, the radio is correctly operating with 40MHz bandwidth.
Unfortunaly, this HT40+ htmode is not properly understood by gargoyle UI when reopening the "Connection->Basic" page. In fact, it shows the "5GHz Operation Mode" as "disabled". This can be quite misleading... Also, if I want to change anything elsewhere in this "Basic" page, forgetting to re-specify all my wifi settings, then the radio finally gets disabled...
You may wonder why I want to disable AC. This is because my other router (WNDR3700v3) which I use as 2nd AP is limited to wifi N and I noticed that fast roaming is better when both AP's share the same operating mode.

A fix for this is also coming.
https://github.com/ericpaulbishop/gargo ... 5f34eb88f4