So far browserleaks.com is the only place that I have seen my Wireguard tunnel be "identified"
Do you think that changing the MTU back to 1500 on the outgoing WAN interface of the exit Flint could fix this maybe?
Thanks
So far browserleaks.com is the only place that I have seen my Wireguard tunnel be "identified"
Do you think that changing the MTU back to 1500 on the outgoing WAN interface of the exit Flint could fix this maybe?
Thanks
It is the MTU of the entire path that is the problem. Basically the MTU of the path is the lowest of all different the MTU's in the path.
Setting the MTU on the WAN will not help, because the MTU in the wireguard connection will be lower (like 1420), because the remaining bits are overhead for wireguard. You likely cannot get the MTU of the wireguard link to be 1500, because then it likely exceeds the MTU of other bits in the route as those would not handle the MTU of 1500+overhead needed for that.
I understand that we need to lower the MTU for the WG tunnel because of the overhead.
I was wondering if something like this could work.
MTU 1420 Set outgoing MTU here on FlintB WAN port to 1500
FlintA --- WG tunnel --- FlintB WAN
Thanks
Setting the FlintB to 1500 will not do anything, because WG tunnel has MTU 1420, which is lower. The highest MTU of that path will therefore be still 1420. Therefore any packets bigger than 1420 will be be able to take that route and therefore not reach that FlintB WAN.
It you were the set the WG-tunnel to MTU 1500, then something on the route between FlintA and FlintB will make packets disappear, because there will likely be something between FlintA and FlintB that will not allow >1500 MTU.
The VPN protocol makes a difference on how well it hides you. I have a GL iNet AR300M that is running OpenWrt 23.05 at a family members home that connects to their 5G home internet router. I run 3 different VPN packages: Wireguard, OpenVPN and SoftEther. Using your test to the same router, using the 3 protocols shows:
https://browserleaks.com/ip
Wireguard using MTU 1280
OpenVPN
OpenVPN
SoftEther
When I am trying to hide that I am using a VPN from sites that check, I use SoftEther, as it is just better at hiding you. It is also much more stealthy so when Wireguard and OpenVPN are blocked by some coffee shops, schools or governments, SoftEther normally works. It is open source and there are packages for OpenWrt. See: https://www.softether.org/
Would I need to run plain OpenWRT on the Flint then, instead of the GL-INET firmware?
I can see a bunch of stuff in the packages.
Under GL iNet 3.2x firmware I was able to install SoftEther along with OpenVPN and Wireguard to work as both a client and server on several different GL iNet router models, but my newest router is an AR750s that is running 3.2x firmware. I have no idea on how to do this on a Flint with 4.x, so it is something that you will need to workout, or give up on GL iNet, and go with generic OpenWrt.
I am using SoftEther VPN Server Version 4.38, as SoftEther 5.x is still considered experimental.
When I updated my VPN server at my family's place late last year, I decided to use generic OpenWrt instead of staying with the GL iNet firmware due to GL iNet's poor firmware support of older routers, such as the AR300M. I was able to get SoftEther, Wireguard and OpenVPN to happily run on my AR300M using generic OpenWrt 23.05 firmware. I have a secure, multi-protocol, VPN server, that uses very little power, gets regular firmware updates, and just works.
If GL iNet ever releases production quality 4.6.x firmware for any of the six GL iNet router models I own, I will try to load the SoftEther client on it.