6 ms·

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?

saberd 5y ago
Are outgoing ports blocked by the university? Wireguard servers usually use port 5000. http://portquiz.net:5000/ http://portquiz.net:5000/
- iso1210 5y ago
  I run wireguard servers on many ports, including 53, 443 and 5-figure numbers. I don't think I've got 5000 anywhere though.
  - 5e92cb50239222b 5y ago
    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/quickstart/ https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/
    - chupasaurus 5y ago
      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.
- jitl 5y ago
  Wow this Portquiz thing is great!
ThatGeoGuy 5y ago
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.
sagres 5y ago
What port is your Wireguard server listening on? It's most likely UDP/51820. Ask them to open UDP + port number.
cge 5y ago
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-192_eduroam-policy-service-definition_ver28_26072012.pdf https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...
- jeroenhd 5y ago
  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.
  - gnufx 5y ago
    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.
trulyrandom 5y ago
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.
jfoutz 5y ago
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.
ngrilly 5y ago
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.

saberd 5y ago

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

iso1210 5y ago
I run wireguard servers on many ports, including 53, 443 and 5-figure numbers. I don't think I've got 5000 anywhere though.
- 5e92cb50239222b 5y ago
  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/quickstart/ https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/
  - chupasaurus 5y ago
    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.
jitl 5y ago
Wow this Portquiz thing is great!

ThatGeoGuy 5y ago

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.

sagres 5y ago

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

cge 5y ago

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-192_eduroam-policy-service-definition_ver28_26072012.pdf https://www.eduroam.org/wp-content/uploads/2020/02/GN3-12-19...

jeroenhd 5y ago
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.
- gnufx 5y ago
  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.

trulyrandom 5y ago

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.

jfoutz 5y ago

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.

ngrilly 5y ago

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.