Gargoyle Forum

Lantis wrote: ↑

Tue Jan 20, 2026 3:17 am

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.

Lantis wrote: ↑

Sat Jan 10, 2026 8:42 pm

fred38 wrote: ↑

Sat Jan 10, 2026 6:53 pm

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

ispyisail wrote: ↑

Mon Jan 19, 2026 9:25 pm

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.

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.

ispyisail wrote: ↑

Sun Jan 25, 2026 8:30 pm

is there a build for the Flint2?

boldga wrote: ↑

Fri Jan 23, 2026 1:36 am

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 wrote: ↑

Sat Jan 24, 2026 5:14 pm

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.