I have 2 Beryl AX routers, one at my home location with Wireguard VPN server running and the other being my travel router acting as a Wireguard client with global proxy so whenever I connect through it, it appears I am at home.
My work laptop runs a software VPN (Global Protect) that needs to be on in order for me to access my work network. When I try running this through the Wireguard VPN, it is extremely slow. My assumption is that it is dropping packets which makes my work pretty unbearable.
Does anyone have advice on how to optimize this setup or troubleshoot? Should I be adjusting the MTU or something else? Thanks!
Sometime setting the remote router’s MTU to 1280 in the Wireguard config helps. Without analysing the packets, this is only a guess.
I have the same issue, my company use Cisco VPN, so I have double VPN connections, my work VPN and my wiregurad client, how ever I am thinking to host my own wireguard server on google cloud or amazon.
Check if you can adjust the mtu of the Global protect.
Also try adjust the mtu of the wireguard.
Have to get the right combination.
Why would this help? Wouldn’t that just make the packets sent through globalprotect larger than the MTU I have set? I am open to understanding further if you can explain.
Can someone advise on how to best analyze the packets? I would have to get my IT team involved in order to change any MTU settings on GlobalProtect, which I can do, but would like to be able to test what I can myself prior to that.
I was having issues with some applications working well with Wireguard, and others hanging or running slow. To me, it looked like not every router along my data path handled the default Wireguard MTU size, and did not properly fragment UDP packets. If the Wireguard packets were full, they got dropped. After some research including reading this post:
I have set the Wireguard MTU to 1280 on my travel routers, and I regularly run a second VPN within my Wireguard traffic, and it works fine. Your VPN software could be fully filling your Wireguard packets and they could be getting dropped along the way. Without doing packet analysis, I could not prove or disprove this.
To test this out, try setting your Wireguard client MTU to 1280 on just your travel router and see if it helps. It would take you less time to do this test then it did for me to write this reply.
Watch using Google. Their UDP packet size it less than 1500 and caused me issues. Wireguard works great on Oracle cloud and they don’t charge for the first 10TB of data egress per month, where Google starts charging at 1GB.
I apologize that I wasn’t clear, I had already tried 1280 MTU without any luck, I was more trying to understand how that was posited to work from my understanding of networking (which is not professional level). Perhaps I’ll try even lower.
I did decrease to 1100 with some improvement, though still not great. Just to clarify, this is the MTU for wireguard client right? I do not see anywhere to set the MTU for the router itself.
I normally only go down to 1280, as that is the minimum MTU supported for IPv6. Yes, I have only changed the MTU on the client side of my GL iNet routers.
A much harder thing to test is using OpenVPN with TCP. I travel a lot, and connect through many different routers, and sometimes I just have problems with Wireguard and other UDP based VPNs, so I switch over to OpenVPN configure for TCP (OpenVPN supports both UDP and TCP configurations), or use SoftEther. SoftEther is a really great open source VPN package, as it emulates an Ethernet connection, but it is not supported by GL iNet. It can be installed manually.
I have not even considered trying openvpn since I read WireGuard was faster but may give it a shot since you mentioned it.
As an aside, what is the method I should use to do packet analysis?
I gave OpenVPN a try. UDP did not seem any better. Strangely, when I try to start a TCP OpenVPN connection, it reads as TCP when I activate it, but when I refresh and view status, it shows as UDP. Not sure why it does that so not having luck in testing TCP. Open to your input.
Edit: I got TCP to work, but it loses its connection constantly and does not seem to maintain a connection reliably. Is this something to expect with it?
I will have to give SoftEther a try as well. I took a cursory look and realized I’m not sure which packages to install, so will have to look in to it further.
I have very solid connections using OpenVPN over TCP, but I am using SoftEther as my OpenVPN server on my GL iNet routers. A lot of times, when the connection has massive packet loss, I have found OpenVPN using TCP work well keeping a connection.
I am running SoftEther on GL iNet 3.12 firmware. I have not tried to install it on GL iNet 4.x. The nice thing about the SoftEther server is it supports it’s native SoftEther protocol, which looks like HTTPS traffic, so it is very good for getting past DPI firewalls. The server also simultaneously supports: OpenVPN (both UDP and TCP), SSTP (Microsoft), IPsec, L2TP, L2TPv3 and the 5.x beta SoftEther code has added Wireguard. It also has a built in DDNS client, and it supports running behind NATed routers without having to open ports.
The downside, unless you have a lot of time, you probably will not get SoftEther working under GL iNet firmware. I spent of lot of my Covid-19 lock-down time making it work, and making sure it would not burn-out the flash, by constantly logging info to flash. Before trying to get it working on a GL iNet router, I started using it on my lab systems for remote access since around 2015, as I needed to support Linux, Mac, Android, iOS, and Windows clients, so I already knew how SoftEther worked, and how to set it up, but it was still a pain to get it to run on a GL iNet router. It is a great package, but its complex. Be nice if GL iNet would support it.
I am moving my 2 GL iNet based VPN servers from GL iNet Firmware to generic OpenWrt, as they are both AR300M routers, and GL iNet’s current support of older, but still under support, firmware is VERY POOR. GL iNet does not have a released production version of 4.x firmware for the AR300M, even-though it has plenty of flash to run the new firmware.
SoftEther sounds like way too much work and probably beyond my level of expertise. I’ll give TCP another try. Ultimately, I may have to just work with IT to adjust the MTU for the work VPN lower than the default which may help. It seems as if any other reasonable option has been exhausted.
Ultimately, it looks like I will have to get a separate router to use for work that does not travel through the wireguard VPN or make an exception on the beryl. I was hoping to just use the Beryl for everything as my main router so all my traffic is routed and stuff like my streaming services will think I am at home, but not a big deal I guess if my work traffic is not routed over the wireguard VPN. Thanks for your help