Inbound connections to many services on PennNet are blocked at the campus border firewall (e.g. SSH since October 2020, HTTP/S since January 2023, etc). This block applies to all inbound connections, regardless of port. Connections within PennNet and outbound connections are not affected.
Servers remain accessible from off campus via Penn’s VPN solution, available to the entire Penn community. VPN users must have an active PennKey affiliation and must be enrolled in two-step authentication. General VPN instructions and client downloads can be found here: https://www.isc.upenn.edu/how-to/university-vpn-getting-started-guide. Information on enrolling in two-step authentication can be found here: https://www.isc.upenn.edu/how-to/two-step-faq
If blocking inbound connections to your server will cause a significant impact to your work, or if you have any other questions, please contact CETS: https://cets.seas.upenn.edu/contact-us/
Linux
If you are connecting from a Linux client, your best avenue for success would be to avoid Palo Alto’s GlobalProtect client. We have had consistently reported success with this open source client instead:
https://github.com/yuezk/GlobalProtect-openconnect
Below is a list of (in)compatibilities with Palo Alto’s GlobalProtect client , as reported by various users as of September 24, 2020:
Reported Compatible: OpenSuSE 15.2, CentOS, RHEL, Ubuntu 18.04 and 20.04
Reported Incompatible: Fermi SL (but see below), Ubuntu 22
A reported workaround is to modify the appropriate /etc/*-release file to pretend you are running a compatible OS with the closest matching paths to SSL Certificate storage. For example, on Fermi SL you might have success using CentOS or RHEL versions of /etc/redhat-release.
If you find you can connect but then lose DNS, check for and remove any manually configured /etc/resolv.conf nameserver entries.
* The University of Pennsylvania’s Office of Information Security continues to see thousands of attacks a day targeting SSH throughout Campus, resulting in multiple host compromises at UPenn. UPenn’s VPN requires two factor authentication, and many SSH servers at Penn do not require 2FA. Best practices such as using key-based authentication, IP restrictions, and other controls are often not followed. There are many devices maintained by vendors that have poor SSH configurations that are difficult to secure.