Long term, the right answer is to have Palo Alto Networks create an official application signature. The good news is that you don't have to wait until that happens.
Here's a few ideas. (I tried the last one and it's currently blocking the app, albiet in an unconventional way). I took this data from what I was able to glean from the iOS app for Apple devices. You could follow a similar process if your students are using a different platform.
1.) permit unknown-udp from your student network to the Internet, but apply a QoS policy/profile and rate-limit it to .001Mbps. This seriously degrades the "user experience" for the app.
2.) look at creating a custom signature. This requires some legwork, collecting pcaps, looking for similarities between sessions, and then creating the pattern that looks for this app.
3.) create a custom report that filters everything out except for unknown-udp traffic from your student network to the internet on UDP 31005/1311/53/123. That report will compile a list of xvpn server IP addresses that you can use to create an IP-based blocklist. You can even export the report via CSV and easily manipulate the data to create this blocklist. Block all of the xvpn servers based on those IPs. (see screenshots)
4.) Automate the creation of an xvpn IP blocklist using PAN-OS 8.0 (this is how I was able to block it).
At a very high level, here's the process: You permit unknown-udp traffic to destination ports 31005, 1311, 53, and 123. This is one fingerprint I've been able to extract from a quick look at the logs. Let's call this security policy "xvpn".
Next, we add a "log forwarding profile" to this security policy. This log forwarding profile leverages two new features in PAN-OS 8.0: Filtered Log Forwarding and Auto-Tagging. This filters through all of the traffic logs looking for entries that match the query: (app eq unknown-udp) and ((port.dst eq 31005) or (port.dst eq 1311) or (port.dst eq 53) or (port.dst eq 123))
Logs that match this filter will trigger an auto- "tagging" action. I chose to tag the "destination IP" with the tag "xvpn".
We then create a Dynamic Address Group, and membership in this group is drawn from all address objects that are tagged as "xvpn" This effectively creates an address object that contains xvpn server ip addresses.
Finally, we come back to the security policy and create a rule that says "block everything, any app, any port, to the dynamic address group we just created.
Here's some specifics with screenshots:
1.) go to Objects / Tags / and create a tag called "xvpn"
2.) go to Objects / Address Groups / and create a dynamic address group called "xvpn" and match the xvpn tag created in step #1 (see screenshot)
3.) go to Objects / Log Forwarding and either edit your existing log forwarding profile, or create a new one.
4.) create a policy that looks something like this. (the log forwarding only needs to be on the xvpn permit rule. also, use log @ session start and log @ session end for the xvpn rule)
With this in place, I've been able to effectively block xvpn in my lab. The first time I launched xvpn and clicked "connect", the VPN session was successfully established. It only takes a few seconds (or hitting one or two webpages) for the above process to kick-off and sever communication with the xvpn server. From there on out it was in a perpetual "reconnecting" status. Subsequent attempts to connect all fail because we're now blocking ALL traffic to that particular xvpn server. Eventually, xvpn recommended a different server, so I successfully connected to that. A few seconds later, I was disconnected and subsequent attempts were blocked.
If your DHCP leases were long enough (ie: 1wk) it might be more fun to tag the source address (the student) with xvpn and block all traffic FROM the xvpn address object to the Internet completely.
One challenge with this approach (especially if you decide to tag the source/student instead of the destination/xvpn-server-address) is that there isn't a way (that I've discovered) to automatically remove the tag after a certain time period. I'm sure you could script this, use the API, etc. That's why I ultimately decided to tag the destination address.
You could also pursue a different method for the automation of this list by using MineMeld. It has a syslog parser and could look for the same log entries that filtered log forwarding is catching. MineMeld would then create and publish an external dynamic list that can be consumed by the firewall. MineMeld has the logic to automatically remove entries from the list after a specified timeframe. The upside is more automation, the downside is spinning up a MineMeld instance and figuring out how the syslog parser works.
Good luck. Would love to hear how it goes.
