Universities do that now? When I was in college, if one connects to the visitor network they'd give you a RFC1918 address with NAT and a restrictive firewall, but if one connects to the regular network and authenticates as a student, they give you a publicly routable IP address.
Depends on a lot of factory. The primary school I was a student at had public IPs at every computer, our national academic and research network operators are encouraging local network operators to avoid private IPs. But the high school at which I'm currently a student, has private IP addresses on every computer and a single external IPv4 for the entire facility. It's not so one sided.
Many will also push http/https proxies regardless of
IP addressing schemes, so even if one user bypasses it,
anyone using defaults will come from whatever the external proxy IP is.
I went to a community college that did transparent HTTP proxying with not just deep packet inspection but caching and "security"-oriented javascript injection. Headers would get reordered, and its parser wasn't perfect so multi-line headers would get broken sometimes. They'd inject JS into pages to scan for... something? Other injected JS? I have no idea. But it was impossible to directly connect to another server without going through their proxy even though from the TCP layer it looked like you were. Lots of difficult to debug issues.
Oh man, an old employer had one that did the same HTTP header monkeying. I discovered it because it broke, of all things, the C2 wiki. I thought the wiki was down when sent a link to a coworker but then checked from my home machine (working remote but over Remote Desktop). And then, of course, had to figure out why it would work at home but not at work :D
I believe it was FortiGate but don’t quote me on that.
It also liked to drop idle TCP connections out of its routing table without sending a FIN or RST. HashiCorp Vault, at the time, only used TCP keep-alive and no additional in-band heartbeat mechanism. Naturally, the firewall dropped the idle connection earlier than the default keep-alive interval (which is long…). Additionally, packets sent to an IP-port combo that it didn’t have in its routing table were black holed, without an RST. We had this painful bug to chase where first thing every morning we could read but not write to Vault for a few minutes and then it work fine for the rest of the day without incident.
I left tcpdump running overnight to see it. At night no one was using Vault… first thing in the morning, the first write goes out to the existing (still valid on both sides according to netstat) but just disappears into the ether. Takes a few minutes for the write to timeout (while spamming retries) at which point Vault closed the connection and started a new one. I just about flipped the table over.
Sadly that's well beyond my memory now. It was pretty formative for me though because I learned a lot of networking and programming and unix stuff so that I could write a TCP-over-HTTP tunnel to a home server just to bypass it. So all in all, great success to be honest.
Interesting. There's a Fortinet product as well in our school. I bet it's corruption and some sysadmin is somehow earning money, because it's so obviously unnecessary.
And it's set to block games. Ironically, I tried playing minecraft on a library computer and the server connection succeeded. Worst of all, lichess.org is blocked so students have to compete using their LTE network during chess tournaments.
It shows that we have a part private part state owned company employed as sysadmins in our school. They don't really understand the needs of the school.
