I've recently bought a GL.iNet AXT1800 mini WiFi 6 router which runs LuCI openwrt-22.03 on top of BusyBox.
I'm trying to get a WireGuard VPN set up in such a way that I can tunnel through the network firewall using TCP port 80 or 443 since this network blocks every UDP port and every TCP port except 80 and 443.
I've successfully built my own VPN client and server using wstunnel and WireGuard on my Windows laptop and Linode Ubuntu VPS and this bypasses the network.
From here, I figured I'd install wstunnel on my router, however it wouldn't run since I need to cross compile it for armv7. Compiling directly on the router is out of the picture since it only has 128mb of flash memory with about 20mb free out of the box since the rest is taken by software/firmware.
Today, I trialed using udp2raw to tunnel traffic between my router and my VPS, and this sort of worked. They handshaked successfully, however soon as WireGuard was set up, the connection dropped. I think my tunnel might have decided to go over the WireGuard connection, which caused it to drop?? Nonetheless, I did the same setup on my Windows laptop with udp2raw and it worked entirely with WireGuard.
I've also had a look into chisel just a few minutes ago but I have no idea how to set this up.
Desired behavior is WireGuard on the router connects to any udp-to-tcp tunnel on localhost, this tunnel then send its traffic over TCP 443 to a remote VPN server which converts tcp-to-udp and sends it back into the WireGuard on localhost:51820.
Any help would be appreciated, and I apologize for any counterintuitive or annoying questions - I'm a newbie here, to both OpenWrt and Linux!!
(P.s @maurer I'm TheFlyingRat on GitHub who replied to your build of wstunnel the other day without luck.)
I'm aware that WireGuard cannot tunnel through TCP out of the box however I am (and have successfully been) able to use a program like Mullvad's udp-to-tcp or Erebe's wstunnel to do this.
The problem lies that I'm unable to do this on my OpenWrt router. I can successfully pull it off on my windows machine hence I'm asking for help on this forum.
Furthermore, you suggested OpenVPN;
This won't work since the firewall uses Deep Packet Inspection (DPI) to block OpenVPN packets (specifically the handshake)
Either way, I need to set up a tunnel on OpenWrt to bypass this firewall, preferably WireGuard over TCP since I get no loss of speed and the firewall doesn't block traffic on TCP 80/443
having a homegrown VPN endpoint that does the proprietary packet-inspection-proof tunneling in outbound direction as you described. This was already solved by you as a proof of concept (though on Windows)
having a router in your local subnet that forwards and likely NAT any outbound traffic of your local clients via your proprietary VPN endpoint service.
So you are as a minimum looking for a solution for the second part + optionally also a way, to host the first part on OpenWRT instead of Windows.
For the second part, I would google the Internet and this forum for posts, who wanted all outbound traffic of devices connected to a OpenWRT router to get tunneled through OpenVPN or Wireguard. Though of course OpenVPN is not what you want, the forwarding part of those recipes of those posts/blogs is likely still a viable match for your requirement. That is a very common scenario, you should find lots of infos about it.
Maybe change the thread title to "forward OpenWRT router outbound traffic to a custom VPN server", as this might give users a better understanding of your issue, who could answer upcoming OpenWRT traffic forwarding questions.
And if you are keen on the first part:
developing/compiling is done differently: There is a dev SDK available for OpenWRT. Used on a regular Linux distro on a PC, output then gets cross-compiled for your desired target platform.
if you have 128MB RAM, running a container can be tight.
looks like it actually runs a vendor fork of OpenWRT 22.
So it likely has some not further specified modifications. Though some people in parallel still seem to work on a community port (which will be some future version). So there might be a theoretical gap between recommendations here and how the device actually behaves. You could also try the GL iNet forum. Not to force you to leave here, but the actual experts for that version fork might rather be found over there.
I don't believe I'm able to do this since I can't install lxc in the first place, and as @Pico mentioned, running a container is very tight on this very low powered machine with limited RAM and storage
I think there is still a misunderstanding. The server (my Linode VPS) is running WireGuard listening on 127.0.0.1:51820 as well as an instance of wstunnel which forwards TCP 0.0.0.0:443 packets to UDP 127.0.0.1:51820.
The client, which in my tests was a Windows machine, used wstunnel and WireGuard again but as a client. The WireGuard config used 127.0.0.1:3333 as the VPN endpoint and ws tunnel would then listen on UDP 0.0.0.0:333 and forward it to TCP [my vps ip]:443 over a pre-established websocket.
Still not getting any luck, furthermore the GL.iNet forum seems to be pretty hostile and dead.
Either way, my end goal is to successfully use my OpenWrt router as a WireGuard client over a TCP tunnel so that all of my router's clients are automatically VPN'd to the WireGuard server.
I already suspected in in the previous post, that your device runs some vendor-specific fork of OpenWRT with unknown modifications (it is not da real thing). The vendor was probably just too lazy, to add some „modified by…“ note.
You may need to clarify this with GL net support or GL net forum people. Or wait until a regular open OpenWRT version gets released for the device
If you have allowed_ips '0.0.0.0/0' and route_allowed_ips '1' options set on the router, you'll need to define a static route for the VPS through the wan interface. This is because in order to pass the wireguard traffic through the udp2raw-tunnel, the endpoint ip address must be set to 127.0.0.1, so the wireguard service will not automatically create the route for you.
I indeed had allowed_ips '0.0.0.0/0' but not route_allowed_ips '1' set up on the router's WireGuard client.
the endpoint ip address must be set to 127.0.0.1
I understand why this makes sense, but what I don't understand is that wstunnel worked without any additional configuration to the WireGuard server...
so the wireguard service will not automatically create the route for you.
Ah, this makes sense why the tunnel tries to go over WireGuard itself. Shouldn't static routes be defined on both the router and VPS though, or just VPS? I apologize for my silly questions
I ran some tests using udp2raw and wireguard on two OpenWrt devices, but the result was very disappointing - 40÷60% packet loss.
Is this situational to how stable the internet is? Both the VPS's uplink and the firewall'd networks are pretty stable (I think?). Often very little packet loss and never above 0.5ms jitter latency. Also, udp2raw in TCP mode (I think it's called FakeTCP), doesn't TCP prevent packet loss? Or is it literally a FakeTCP that are actually UDP packets with TCP headers?
Alright.. It is indeed a vendor fork of OpenWrt, and comes with some inbuilt programs that control the fans, LEDs and random stuff related to the hardware/firmware interface.
It is not a very stable OS + hardware pair for sure, and under even a little bit of CPU load (not network load) gets very slow and sometimes straight up doesn't work until you yank the power cable out.
I'll have a lot at wireguard-proxy soon. It seems interesting and it could work..
OpenVPN will never work - It's handshake is blocked by deep packet inspection
Additionally, you said sstp vpn
I had a look at the sstp protocol on wikipedia, and saw this clause:
SoftEther VPN, an open-source VPN server program which supports SSTP-VPN protocol.
I have historically used SoftEther in the past, and it did work!! However, one day, it got entirely blocked. I'm unsure how they blocked SoftEther since it used SSTP/HTTPS as per:
But nonetheless it got blocked - I assume since the Firewall/Proxy decrypts the traffic between the VPN server and itself, thus can realize it is a VPN packet and drop it between my computers connection to the proxy.
My implementation of WireGuard over WebSockets probably worked since the proxy didn't realize the WebSocket was a VPN packet since its unlikely it has seen wstunnel on the network before.
Requests coming on tcp port 443 on the wan interface of the server are forwarded to udp port 51820 (the wireguard listening port) on localhost.
That's why the endpoint address shown is 127.0.0.1:<some_random_port>.
root@Office:~# wg
interface: wg0
public key: =
private key: (hidden)
listening port: 51820
peer: =
preshared key: (hidden)
endpoint: 127.0.0.1:39130
allowed ips: 10.9.8.2/32, 192.168.2.0/24
latest handshake: 1 minute, 42 seconds ago
transfer: 1.34 MiB received, 6.44 MiB sent
persistent keepalive: every 25 seconds
You need to create a static route only on the router and it should look like this:
#/etc/config/network
config route
option target '1.2.3.4/32' # VPS public ip
option gateway '5.6.7.8' # wan gateway
option interface 'wan' # wan interface logical ifname
Unfortunately no. For the tests I used an existing permanent wireguard connection, which usually works flawlessly. The problems started as soon as udp2raw was involved...
I've tested WireGuard over shadowsocks-libev proposed by @maurer and it works.
The tunnel endpoint is best routed with PBR as it eliminates the need for WAN gateway.
I appreciate your response and I apologize for my late reply - been busy with life things...
Regarding your solution, what do you mean by this?
Particularly, what's a PBR and what do you mean by WAN gateway?
I understand what both acronyms mean however why would I need to eliminate the WAN gateway, if, what WAN gateway? The router is acting as a repeater so I can secure the repeated (public/corporate) network and use my own devices while on a VPN, thus I assume the WAN gateway in this instance is the gateway on the repeated network?
This is not specific to your setup, but it is generally a better option as it fits both static and dynamic setups where the WAN gateway may change over time.
