We would like to block the application X-VPN (used on apple iOS system as a VPN app). Using PAN-OS 8.0.1
The firewall sees the traffic as either SSL, web-browsing or google base traffic and doesn’t appear to be decrypting it.
The session ID says the URL is for bing.com in the session but the destination is 22.214.171.124.vultr.com which is where the VPN is hosting their services.
We have tried the following:
Change service (under Policies/Security) to application-default
Select block all sessions (under Objects>Decryption Profile>SSL Proxy)
Any thoughts on this?
Thanks in advance.
We logged a support case for this and in the end it was a Feature Request.
At the moment, you can either create custom appid or block any offending traffic ports, etc. or wait for app to be created.
Does your environment use ssl traffic on non-standard ports like 80?
If not, try allowing ssl only on default port if that is not used.
If the traffic is allowed only through web-browsing on port 80 which is it's default port, unless you see a specific pattern or it trying to go to any URL, you will not be able to block it without an application for the app.
Below is some excerpts from the case.
Application is identified as insufficient data when we do not have enough data to match to a known application,
or not enough packets are received to be identified as unknown.
Since it is a public app, you can submit a request for new application from the research-center link provided in following doc-
(This doc also has procedure for creating custom-app-id and links to doc on how to create custom app signature)
This will trigger a issue ticket in our back-end for our application development team to work on.
You may be contacted on the email provided for any clarification or details as required by app team.
Alternatively, you can create custom signature -
You can also block the ports used by the app, but this is only best effort as VPN app will eventually get through different method.
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.
Unfortunately, our firewall is identifying the traffic as dest.port 80 which is making it hard to identify.
I'm guessing there is something fundamentally wrong with our firewall rules that is causing our problems.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!