Hacker News Reader

Comment by protoman3000 | Hacker News Reader

We still can’t get WireGuard to work if the client uses the WiFi on our university campus. Does anybody have an idea how to overcome this?

View on HN

If the wifi is eduroam, as many are now on university campuses, you should take a look at the service standards [1], especially page 32. While recommendations (on page 33) are only to block a minimum number of ports, if needed, in practice, I've found that some universities block all ports except those they are required to have open per eduroam policy. This includes blocking all UDP ports except 4500, 1194, and (outgoing only) 500. The trick of using common TCP ports won't work on these networks, as they open those only for TCP per policy, and often only outbound. On those networks, I've found using port 4500 for WireGuard works.

This is a bit annoying, because the policy is clearly designed to ensure that VPNs work, it just isn't written to support WireGuard yet.

[1]: https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...

Funny, the eduroam universities I've been to never blocked any outgoing traffic based on port number alone. In fact, one of them essentially provides you with a world routable IP address, only blocking some incoming ports known for abuse such as 25 and 53. A port scan of the network is a reminder of how badly the world has been relying on NAT to provide security (which it doesn't even do in the real world) because people will just permanently disable their firewall and think nothing of it. Once you hit the wired network, all ports are free game, which is even worse! Luckily, these networks are scanned and honeypots/badly configured servers will get hit with a warning in hours to minutes.

My solution for those restrictive networks is to pick common ports as well. Outgoing ports 53 and 443 work in most networks I've tried, even for UDP. Running a WireGuard server on port 53 means you can't run DNS from that server, and running a server from 443 means no HTTP/3 or QUIC. If the goal is to run a server from behind Eduroam then I think you'll be tough out of luck.

I suspect there's a big variation, particularly in whether the university has placed the keys to the kingdom in the hands of a "partner" of, shall we say, dubious competence and understanding of academia, after getting rid of decades worth of local experience. Fortunately those with decades of experience outside Networks group can usually find an "impossible" way to work around notwork and other roadblocks, but it's so much wasted time.

Why are they doing this at all? I don't think it's in the name of "security", if you can establish any VPN connection, you can easily exfiltrate any kind of traffic without anybody noticing.

Usually to protect the random unprotected machines on the local network (and the rest of the world from the poorly administered machines), in my experience.

Some of it often boils down to mindset of the admin - allow everything unless you know it is a problem, or block everything unless you ‘know’ it is good.

In the name of security for the millions of BYOD devices that connect to eduroam. Only 0.1% may find inbound or strange ports useful but probably a double digit percentage of BYOD devices find unfiltered networks (particularly inbound or peer to peer communication) to result in massive continuous malware outbreaks.

I have some tangential experience with a big sprawling old university network. It's a hard job. On the one hand, you need to protect academic freedom. Someone really is writing a paper about sexuality and needs access to crazy port sites. There's also the 90 year old advisor that never really understood email and why it's bad to click on every link.

Reach out to a professor, and write up a paper proposal about practical deployment of wireguard. You should be able to get some access to university IT folks. Not like, help desk, but net engineers. Take notes, capture the details about why it's tricky, and how you solve it.

You're not going to get into a journal for pure research, or anything super fancy like that. But if you put in the time, you'll get wireguard working and get a little credit on campus as not being clueless.

Are outgoing ports blocked by the university? Wireguard servers usually use port 5000. http://portquiz.net:5000/

Wow this Portquiz thing is great!

I run wireguard servers on many ports, including 53, 443 and 5-figure numbers. I don't think I've got 5000 anywhere though.

Same. Not that it means much, but I've been seeing 51820 being used in all documentation, blog posts, etc. Probably just copypasting the original examples, e.g.

https://www.wireguard.com/quickstart/

https://www.wireguard.com/xplatform/

A month ago I dug through the history, the only trace to origin of using 51820/UDP I've found is that the number is hardcoded in one of the tests.

You could try running Wireguard over port 443. Since HTTP/3 also uses UDP and port 443, it's possible that the university network doesn't block this.

There is a whole host of things this could be, but you may want to talk to your University IT and determine if they're doing any kind of port blocking, NAT blocking, etc. on the network.

Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.

What port is your Wireguard server listening on? It's most likely UDP/51820. Ask them to open UDP + port number.

We had the same issue. Setting the MTU to 1280, the IPv6 minimum MTU (we use IPv6), instead of using the default value, fixed the issue.

Reply on news.ycombinator.com