I'm in an academic department and we've historically blocked outgoing traffic for two separate reasons. First, we consider some protocols actively unsafe to use because they transmit credentials in the clear, and we didn't want our users to accidentally do that. Telnet? Rlogin? Sorry, no. Second, we're in an academic environment where the attacker may be inside our network and poking at someone else's, so we want to shield outside parties from bad traffic we may be generating. In both cases, we're responsive to our users; if someone says 'I need this port', we'll allow the traffic (although we try to be selective about the destination).

(The third answer is that when we set up firewalls in the beginning, we consciously decided to start with a 'default block' policy.)

(I'm the author of the linked-to entry.)

Perhaps they were trying to block (encrypted) P2P downloads and gaming. In such case it would be a "good enough" solution, because it is hard to convenience every each P2P peer or game server to use whitelisted ports.

Detecting protocol is hard, and much expensive than just port blocking. So I guess the admins were trying to do the best job possible with the limited equipment on their hands.

Detecting bittorrent isn't that hard, and neither is detecting most popular p2p traffic. It's CPU intensive though, requiring something like snort to run basic protocol heuristics on every packet. Just blocking as much outgoing udp as possible would be the poor man's solution to a network policy like that. There's also ways to cloak network traffic, of coarse.

Of course, in practice, all of the bandwidth can still be sucked up by p2p through VPNs which are probably allowed through the network, so I'm not really sure what the problem those restrictions try to solve is.

I think my classmates in IT school learned much more from bypassing the network restrictions to play WoW in class than from the teachers themself.

We just ran our own servers on port 443 - We tried 80 at first but I guess they did have something rejecting non-http traffic on that port, while I guess for 443 they just assumed everything not understood was https.

Also LoL worked whatever they did. Maybe that was just the admin's game of choice

Back when I faced similar issues SSHing to my home network from school and work, I forwarded port 443 external to 22 internal.

Very few people would be so silly as to close outbound port 443, and everyone expects that port to see encrypted traffic anyway, so it seemed like the logical choice.

It makes sense on a network with only managed servers - couple the firewall deny in with flow logs and forward to your monitoring system, it’ll alert you to suspicious traffic.

However on a general purpose network I agree. If you’re not using the outbound blocks to alert on you’re just inconveniencing someone who can work around it.

I have WireGuard endpoints on several ports including 53 and 443 to maximise the chances of getting through

Layer 4 doesn’t have any way to understand layer 7 though without some sort of deep packet inspection. That’s outside the realm being reasonable in a lot of cases.