I was able to set up my wireguard server and I’m trying to use my a travel router client. After many errors I was able to set to connect to the server but the speeds are incredibly slow cannot open any pages. Any tips?
Router: GL MT3000
Firmware: 4.4.6
LAN connection
DNS:8.8.8.8
static IP address
my home router has post forwarding to the wireguard server could it have something to do with that
Why is your server listen port set to 1? I would just leave it at default or use something similar, but port 1 may cause you other port filtering problems when traveling. Plus, that ensures your wireguard server process is running as root, which it should not be imo. As @admon said, we need more information.
this was the default that was listed on my ISP application when i created the port forward. Should I change it to the default one that came with the router which was 51820? Also when i make these changes should i be changing them server side as well i assume? what should the MTU be? I set it to 1200 because of a post i saw on reddit
You should probably try to read a little more on how to test for MTU. It will depend on what your ISP has their MTU set to. You are likely using 1500, and the wireguard default MTU of 1420 is probably fine. I would not adjust that until you actually test for MTU. If you are using PPPoE or cellular, you might be more likely to need to change MTU than if you are not.
As for which port to use, I do not use 51820, but I use something close to that. I don’t like to use default ports that are likely to be scanned so it doesn’t fill up my logs. UDP scanning is very slow and most scanners are looking for commonly used ports. From a security standpoint, I don’t think it really matters. IIRC, the first packet sends auth info and if that fails there are no responses provided. It is a rather safe application in that regard. All software can have a bug, but the exposure for wireguard is really light so far.
Definitively change the WireGuard port back to the default one - you can try to adjust it as soon as your connection is stable.
just to confirm default one is 51820
Yes, that is correct. udp/51820
understood will update when i get home, I saw the DNS from set from my ISP was 75.75.75.75 will update as well. what othe?r information can i provide that would be of assitance?
Change your MTU back to 1420 for now. Do some googling on how to set the right MTU. How are you currently connecting to the internet right now? Ethernet? Do you have to provide a username and password for your internet connection?
though luckily wireguard is designed to not respond to a failed auth request so the port scanner will not know the port is open because the protocol is udp👍, tcp is more of a issue since it replies with a icmp reply which makes the port presence for the scanner.
Nevertheless for security using a different port is fine.
Not entirely. UDP will still respond with a port unreachable icmp message if the port is closed (be default, this can be changed). If the port is open or the ICMP return is filtered, you don’t know if the port is open or not. UDP scanning is a thing, and if someone is looking for wireguard services, they will use 51820. UDP is too slow and unreliable (reasons above) to effectively mass scan. So if I am running my wireguard server on a different port, then I can ascertain that any other attempts to 51820 should be considered malicious.
this is true but not if the input is set to drop 
I believe GL firmware has it to drop by default, but standard OpenWrt has it to reject.
Sorry, wrong reply initially.
Mine is set to accept, accept, reject.The rule for wgclient specifically is set to drop be default. I cannot tell you how traffic gets selected to the wgclient interface. I just tested and sent a udp packet to the public interface on my server on the wrong wireguard port and it is being rejected and returning icmp port unreachable, not dropped. I do not believe I changed that, but it is possible. In any case, why should I subject my wireguard server to scanners unnecessarily?
For testing purposes I’d go with a WireGuard MTU of 1280. You can optimize it later after establishing a stable connection. 1420 definitely suffers from fragmentation over cellular.
Edit per @packetmonkey’s valid comments. 1420 MTU did not work well for me using Verizon’s cellular network. Just did a few test to confirm using Verizon 5G NSA.
No VPN: 456 Mbps
1392 MTU: 159 Mbps
1420 MTU: 18 Mbps
Not always man. These blanket statements are hard to take. My cellular connection has a MTU of 1480. MTU of 1420 on wireguard using IPv4 is still fine. You have to test your MTU to see what it is.
Valid statement. I still stand by my recommendation to use 1280 initially and optimize once the bugs are worked out.
Then I would counter that and say you should first set the MTU on your WAN interface to 1360 if you are going to limit wireguard to 1280. Because the MTU of the WAN interface is what will drive the need to lower the MTU on the wireguard interface.
I want to run some tests myself, too, because I have seen from other reports how much of an impact MTU can have. While some variance can occur with small manipulations, most of the improvement comes from adjusting the wireguard MTU to 80bytes smaller than the actual MTU of the WAN connection to account for standard IPv6 headers. Otherwise, you would need to run a lot of tests, especially for cellular-based connections, and average over time to account for environmental or congestion influences.
My connection is via T-Mobile Home Internet and 1480 was the MTU of the wan connection based on mtu discovery. So I have my MTU set as 1400 currently. It has been clean since 4/29 (have had off and on trouble with dropped packets over the VPN only, regardless of the MTU size that appear to be on the TMHI side). I need to get to the remote site so I can more easily play with the MTU. BTW, tailscale has the exact same issue when wireguard is dropping packets, so it is not just the GL-iNet wireguard implementation at play. I really think TMHI is having trouble with UDP packets somewhere. Even when wireguard and tailscale are acting up, I have a clean connection to the internet. My wireguard is split tunnel by the way.
Sorry that is all so hard to read…busy day.
