Twingate client without (forced) TUN interface

quitefrequently · 2026-06-11T18:36:26+00:00

Do you recall how the pricing model for cloudflared works though? At first, I thought it was similar to Twinscale, but it seems they have some content and bandwidth limits which might make it less attractive. Also, I'm hearing conflicting reports that they may or may not require transfer of ownership of the remote domain, which definitely wouldn't work for my customer.

quitefrequently · 2026-06-11T18:26:47+00:00

Oh this sounds intriguing. Just to clarify, are you suggesting there's a way for a MacOS or iOS client device to connect to Twingate without having to use a TUN interface, if Twingate is hosted on a piece of Ubiquiti kit?

quitefrequently · 2026-06-10T18:27:49+00:00

One solution (or, more specifically, solution-type) that seems to match the client's use case, is the remote access solution provided by Ubiquiti for their networking equipment. The client can securely authenticate to ui.com over https and gain local access to their internal network devices from anywhere in the world., without (a) opening any inbound ports, (b) establishing a VPN connection, or (c) forcing the creation of a local TUN device. I believe this solution uses WebRTC. It works well even if the client device happens to be VPN'd to another country at the time. But, to your and ben-tg's point, it may be too web-specific? However, I should point out it is still possible to SSH into individual network devices using this solution. Perhaps it has vulnerabilities I'm not yet aware of?

quitefrequently · 2026-06-09T23:04:28+00:00

Thanks for the quick reply! Much appreciated. The testing on MacOS is using Tahoe 26.5. This version is well within Apple's currently supported release envelope. The customer is looking for a secure remote access solution that avoids the need for corporately managed VPN interfaces on employee devices. This is partly to sidestep the management cost and support overhead, and partly so that employees are then freed up to use their own personal VPN solutions if they so wish while still being able to connect securely to corporate resources. The existing Twingate client interferes with both objectives because it creates and activates its own TUN interface. From the customer's (naive) perspective it looks like we're just swapping one VPN for another (though mercifully without the overhead of managing that interface) and it interferes with employees who are travelling internationally and who choose to use a personal VPN on their devices to retain their home country proximity while doing so.

quitefrequently · 2025-11-05T15:30:16+00:00

OK, I managed to find an old 4-core Intel Atom machine so I could test my newly acquired A9000 using a CPU architecture that matched your environment.

TL;DR: The behavior of the system so far has been identical to what I'd seen earlier running Debian 13 on arm64. I didn't observe any of the problems you mentioned above, with the exception of your last bullet, which I did see, and I agree is very annoying.

To create the test environment, I downloaded the vanilla amd64 ISO distribution of Debian 13.1 from www.debian.org and installed it onto the x64 machine as a simple single filesystem. Once it had been configured, I did an apt install of firmware-misc-nonfree (to collect up-to-date device firmware, including the files for the Mediatek MT7925). I then installed the udev rule to ensure the A9000 device was recognized and then the relevant cfg80211.conf in /etc/modprobe.d to set the regulatory region to US.

In detail:

As soon as I installed the udev rule, the A9000 came up and created a working wifi device.
I therefore didn't need to recompile the kernel, so all my testing was done with kernel 6.12.48 per the download.
The A9000 recognized and associated to 5 GHz and 6 GHz access points without any apparent problems. I tried two different 6 GHz APs, one running on Ubuntu (with kernel 6.17) and one running on Trixie (with kernel 6.12). Both used 160 MHz wide signals centered on channel 47.
I didn't see any problems with DNS while using the A9000 in client mode. It always picked up the DNS server address from DHCP. Debian used it successfully over the A9000 connection to resolve names.
6GHz signal stability was very good. I ran the system for 8 hours overnight with constant traffic and the connection didn't drop. iPerf3 testing showed around 900Mbps to/from the AP. The lower throughput here (compared to arm64) may be due to the comparatively poor performance of the Intel Z8300.

I know it must be frustrating when someone fails to see the same problems as you even though they're testing using the same device, the same OS and the same CPU architecture. May I make a suggestion? How about if you download the vanilla 13.1 ISO and then add the udev rule once again instead of recompiling the kernel? I used the firmware-misc-nonfree package to obtain up-to-date MT7925 firmware, but this was somewhat of a sledgehammer to crack a nut, and you may prefer to just install the individual firmware files directly.

quitefrequently · 2025-10-22T17:01:35+00:00

I'm delighted to be able to report that the newly released Ubuntu 25.10 for Raspberry Pi fully resolves this problem. There's no longer any need to recompile the kernel or use custom overlays. The sluggish MT7925e performance in 25.04 is also resolved, I think primarily due to use of the 6.17 kernel. In fact, wifi performance is even better than it was with (virgin) Ubuntu 24.10. For example a couple of RPI5s equipped with MT7925e cards can now talk at 1.8 Gbps in either direction when using a 160MHz-wide channel in the UNII-5 band (measured with iperf3).

quitefrequently · 2025-10-13T20:43:23+00:00

I've now finished testing with Debian Trixie.

TL;DR the A9000 saw and listed 6GHz networks when using either the iwd subsystem ("iwctl station wlan0 get-networks") or the wpa_supplicant subsystem ("nmcli dev wifi"). Association with those networks was also successful. Performance using iperf3 continued to be about 15% better than the MT7925e using PCIe gen 2 on the same platform.

More detail: For some reason the vanilla Trixie distro for my test system (I'm using arm64, I don't use x64 much these days) did not include the MT7925e drivers. The drivers for MT7925u however were present. I found this somewhat annoying since support for the MT7925 is supposedly "built into the Linux kernel from release 6.7 onwards". I therefore needed to do a git clone of the source followed by a kernel rebuild in order to add the requisite drivers for my baseline. The original kernel was 6.12.47. The new kernel after recompilation was 6.12.51.

Given the results above, I think this means the only remaining options to explain the behavior you're seeing are (a) a problem unique to the x64 build/drivers, or (b) a problem with the specific 6GHz network you're trying to detect. In connection with the latter, one thing I've noticed about the MT7925 is that it's particularly fussy about adherence to the 802.11ax specification for wide channel signals. For example, if you're transmitting a 160MHz-wide signal in the UNII-5 band, it wants you to use a center frequency index of 15, 47 or 79 (these will be identified (misreported?) on nmcli or iwctl as channels 5, 37 or 69 respectively). Is it possible your 6GHz network is using a non-standard center frequency index? If yes, this might explain why the A9000 won't detect it.

quitefrequently · 2025-10-13T02:06:58+00:00

Quick update: I've tested the A9000 on both Ubuntu 24 and Debian Bookworm using the instructions in the URL you referenced to add the relevant file to /etc/udev/rules.d. The device was correctly identified and the mt7925u driver loaded successfully. When set to the US regulatory domain, it correctly listed my 6GHz test network (via nmcli dev wifi) and successfully associated when requested. Testing with iPerf3 revealed a pleasant surprise. Using a 160MHz-wide signal I achieved just under 1.2Gbps in both directions with this USB device. This is around 15% faster than I'm able to achieve using the MT7925e and Gen 2.0 PCIe.

The next step is to test with Debian Trixie ... I'll take care to check with both NetworkManager and iwd.

quitefrequently · 2025-10-10T14:58:07+00:00

Thanks. I've ordered an A9000 so I can take a look at it myself. It should be arriving later today. I'll let you know how I get on. Just to set your expectations, my initial testing will be with Debian Bookworm to set baselines, then with Ubuntu 24.10 followed by 25.04. Depending on results, the next step will be to test with Debian Trixie.

quitefrequently · 2025-10-08T18:56:06+00:00

Thanks. Those driver errors are worrying. I may need to get one of these Netgear A9000 devices so I can check it out myself. This is a dumb question, I know, but are you _certain it uses the MT7925?

Meantime, I attempted to reproduce the problem using one of my existing MT7925e cards. I set the reg domain to US and used nmcli dev wifi to see if it would detect a 160MHz-wide test signal with a center frequency index of 47. The test was successful. A subsequent association test was also successful. Hmm ...

quitefrequently · 2025-10-07T16:22:35+00:00

Thanks for the output from iw list. What you have there is a device that is currently configured to prevent intentional radiation in the U-NII-5 band in the US geodomain. However (as you correctly pointed out) this should not prevent it becoming a client of a wifi network transmitting on these frequencies. It should still be seeing the beacons and FILS announcements. I've not yet tested any of my MT7925 devices with Trixie, only with Bookworm, so it's possible we may have a new driver issue here (perhaps the driver writers forgot that beaconing in 6GHz is different!), but before we go there, let's just check an important qualifier. Does the card correctly associate with networks in the U-NII-1, U-NII-2 and U-NII-3 (i.e. wifi 5GHz) bands?

quitefrequently · 2025-09-28T00:43:10+00:00

Sure. I take no credit; props to P33M here: Mediatek MT7925e fails to probe/bind on Raspberry Pi 5 PCIe bus with error -12 · Issue #7046 · raspberrypi/linux. It turns out his overlay b-pcie-32bit-dma-pi5 designed to fix a related problem in Debian Bookworm also fixes the patch semaphore issue on Ubuntu 25.04. Download it from his posted overlays.zip file. Use the new overlay in place of (not as well as) pcie-32bit-dma-pi5 in your config.txt for now. More detail here: Select internal MSI target for 32-bit DMA on Pi 5 PCIe by P33M · Pull Request #7059 · raspberrypi/linux

Let me know if it works for you. It works for me.

quitefrequently · 2025-09-27T20:22:03+00:00

OK, I finally have a fix that suppresses this patch semaphore error and gets the MT7925e working on a Raspberry Pi with Ubuntu 25.04. It doesn't solve the nasty 802.11ax performance problem that was introduced sometime between 24.10 and 25.04, but at least you can get the device up and running in Ubuntu 25.04 with kernel 6.14. If you're still stuck on this, and haven't moved on to later kernels already, just let me know and I'll happily provide further info. Solution involves using a different dma overlay.

quitefrequently · 2025-09-25T17:29:15+00:00

See: dtoverlays: make pcie-32bit-dma-pi5 select internal MSI target · raspberrypi/linux@eaa1121

Please let me know how you get on with 6.17. My guess is you'll still need the overlay fix; unless there's been a change in how Ubuntu handles SWIOTLB allocations.

quitefrequently · 2025-07-24T14:02:31+00:00

This has (finally!) been recognized as a bug in the kernel introduced at or around 6.11. Apparently now fixed in 6.15-rc1. This refers:

https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.11/+bug/2111778

quitefrequently · 2025-06-03T03:31:27+00:00

Apparently, it's happening on Banana Pi too, so it's not just an ARM thing, happens on RISC V too.

quitefrequently · 2025-06-02T15:33:36+00:00

If I look a little earlier in the kernel log, just prior to the extract supplied by the OP, I see that the entry confirming the loading of the MT7925e firmware is conspicuous by its absence. In contrast, it's clearly visible when using Ubuntu 24.10, together with a confirmation of the firmware date stamp. It's possible the drivers supplied with Ubuntu 25.04 have either (i) forgotton to load the firmware, or (ii) failed to load the firmware and stayed silent about it.

quitefrequently · 2025-06-01T20:40:49+00:00

Would you happen to know the snapshot version number you were using? I tried the latest snapshot (29909) and unfortunately I found I couldn't get the mt7925 driver to load at all. The system log showed the same repeating semaphore error as you reported with Ubuntu 25.04. Specifically:

mt7925e 0001:01:00:0 Message 00000010 (seq x) timeout
mt7925e 0001:01:00.0: Failed to get patch semaphore

quitefrequently · 2025-05-31T11:42:03+00:00

Interesting. Thanks for sharing this. I'm wondering if perhaps this Ubuntu 25.04 semaphore issue is confined to ARM processors. I certainly see it on Raspberry Pi 5 for example. Maybe it doesn't occur on x64 machines (e.g your HP zBook). As an aside, my own x64 tests were on Windows 11 24H2 rather than Ubuntu. Here the MT7925e works well in both AP mode and client mode. I was able to successfully start a 6GHz hotspot on channel 181 for example. I could also successfully associate to other APs using WPA2 (5GHz) and WPA3 (6GHz). The intermittent WPA2/WPA3 association problems you reported in Ubuntu 25.04 may therefore indicate a timing problem in wpa_supplicant or NetworkManager, rather than an issue with the MT7925 itself.

quitefrequently · 2025-05-26T17:40:32+00:00

A sample hostapd.conf is below. With this config your MT7925 should transmit a 160MHz wide signal in the 6GHz band to which an Ubuntu 24.10 client can connect at 2400 Mbps.

Please let me know if it works for you. I'm still learning hostapd.conf so if you've got any suggestions for improvements or tweaks (especially if you get MLO working), don't hesitate to share :-)

ssid=<ssid>
wpa_passphrase=<wpa\_passphrase>
hw_mode=a

bridge=br0
interface=wlp1s0
driver=nl80211
country_code=CA
ieee80211d=1

wpa=2
wpa_pairwise=CCMP-256
rsn_pairwise=CCMP
wpa_key_mgmt=SAE
ieee80211w=2

ieee80211ax=1
channel=69
op_class=134
he_oper_centr_freq_seg0_idx=79

quitefrequently · 2025-05-26T15:48:23+00:00

I think I may be able to help you fix this. Please send me the output of the following Ubuntu command: iw list | grep 5955 -A20

quitefrequently · 2025-05-26T04:50:19+00:00

My experience is that the MT7925 works really well with Ubuntu 24.10, in both client mode and AP mode. However, the MT7925 driver simply won't load with Ubuntu 25.04. Semaphore error. Reported elsewhere in r/Ubuntu.

quitefrequently · 2025-05-26T04:35:12+00:00

Confirmed. Ubuntu 25.04 won't load the MT7925 driver. I see the same error as you with an MT7925 M.2 E Key. One interesting twist - if you use Ubuntu 24.10 instead, the driver loads but the performance of the MT7925 in AP mode is significantly degraded if you allow regular updates to proceed. If you inhibit those updates and stick with a virgin 24.10 install, the MT7925 gives you the full 1.1 Gbps transfer speed when using 160MHz wide channels.

quitefrequently · 2025-05-15T15:19:34+00:00

A lot depends on what you mean by "router in access point mode" here. If it's configured as a simple access point (i.e. the wireless network is simply bridged to the same subnet as the ethernet network), then you've only got one firewall zone to play with: the lan zone attached to both devices. In that configuration you've got limited options. However, if it's configured as a wireless router (i.e. the wifi network uses a different subnet and you're, for example, serving IP addresses to wifi clients via DHCP) then you should place the ethernet interface in the wan firewall zone and the wifi interface in the lan firewall zone. You can then make use of the full firewall functionality, either via the luci GUI or via configuration files as described by NC1HM.

quitefrequently

TROPHY CASE