I'm trying to understand how WG tunnels are detected.
Consider a topology like this.
Laptop (BT, WiFI disabled, physically connected to Beryl WG tunnel) --- (Flint WG server at home internet connection in home country to internet)
Laptop uses CompanyA VPN to connect (VPN within a VPN I guess)
How could CompanyA "know" that the traffic originated via a country to country WG tunnel?
I can't get my head around how the packet coming out at the head end router would show WG origination. I guess you could look at maybe RTT or TTL. I'm missing something here...
EDIT: ipleak and all DNS checks show the endpoint "home country" so if you are WG from EMEA to US it does show the US address, and it's a home address not a VPN service. DNS is cloudflare. All is good... usually
The only indicator could be the added latency which is not really something you can change, but you can also tell them you are on bad wifi, tcp on the other hand maybe works a little better.
the difference between udp and tcp is that udp does not have a keep alive mechanism, so if a packet is lost it is lost contributing to more latency, tcp resents the packet this way you may lag less because the home server must receive the packet.
just to explain this further:
vpns encapisulate hops, so your public ip turns into the companies one, and the endpoint visible at the remote company is your home ip from the server.
It is not possible for them to do any of the deep packet inspection or look into your tunnel.
To demonstrate im currently connected to a wireguard server on Mullvad, by chance the same ip also hosts a openvpn server, and it reports openvpn, even though i do not use it.
This isn't a hard indicator, you could also say you portforwarded it for a game server for example the business would not know the difference only that it is a known commonality with vpn ports.
You can also make it look closed by using udp protocol.
wireguard is a much better option for this since the vpn does not respond, its faster aswell, although both should be fine aslong the protocol is set to udp.
Jup, the port which is open on the server needs to be only open for udp and the vpn needs to use udp protocol, it must not have tcp open because tcp can respond with a icmp packet that the port was unreachable, blocked that packet gives them knowledge that port is open.
Please go to advanced settings -> login (same credentials as gl ui) -> network -> firewall -> traffic rules tab.
can you see the rule of the vpn server with the open vpn port?
what does the protocol say?, it must be udp only.
If not i'd recommend making a copy of this rule and disable the generated one by gl firmware, im not sure if they automatic allow tcp too but for hiding a wireguard vpn server this needs to be udp only😉
The MTU is not issue, the mtu is not what browserleaks detect.
But if you test it on the laptop with the corporate vpn active (which is openvpn likely), then the site reflects the corporate vpn and it sees a open port on their side
MTU is the one they detect. Port detection isn't working like that.
The MTU will give a pretty good hint. 1492 is the MTU for PPPoE, for example.
1420 for any VPN. 1380 for OpenVPN UDP ...
The site is trolling just tested it with 1500 mtu, it shows it as linux kernel 2.0 with 1492 mtu, also the location shows in braband when other sites say amsterdam.
It looks to the next hop which likely has this exposed so it must be the pppoe server.
Looking at it, they seem to detect the MTU and hops on their server. It is very likely they simply have low level access to the webserver connections. Their webserver will of course need to figure out what MTU to use (using PMTUD), so it can send the biggest possible packages back. Hops is very likely result from TTYL.
Based on the MTU they just guess it might be a VPN, because a VPN needs to have a lower MTU as it needs a bit for overhead to transmit its own data.
