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.
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.
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.
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.
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...