Personal VPN Services thwarting Company Policies

[Jaragorn]

Downstream of our PAN's, we have our Citrix environment.  This environment includes some Netscalers that have a nice feature in that they provide in their SYSLOG, two fields named "ClientIP" and "NATIP".   This proves quite useful in that while the ClientIP field geolocates to a local Boston IP address, the NATIP address shows they are coming in from, for example, Spain.   While we have rules in our PAN that should prevent these non-US connections, the VPN services apparently use a local proxy that thwarts the PAN's location lookup.

I've searched and can't seem to find if the PAN's can present and utilize something equivalent to the Netscaler's NATIP so as to be able to leverage it in a policy rule or not.

Note: I have the TOR rules setup but these connections are not TOR.

Any ideas?

Thanks!

[OtakarKlier]

Hello,

Is this inbound or outbound traffic? Also what application does the PAN see it as? Do you have ssl decryption enabled?

Regards,

[Jaragorn]

The traffic of concern is inbound traffic that is properly identified as SSL and DTLS without decryption.

[OtakarKlier]

Hello,

So in the detailed log view when looking at one of the completed sessions, the IP listed is the US based one?

Regards,

[OtakarKlier]

Sorry should have been the 'Source' not destination.

[Jaragorn]

Correct, the source shows as US by virtue of the VPN service the user employs.  Looking up the source IP shows it belonging to NordVPN. 

[BPry]

@Jaragorn,

Do these users need to connect to GlobalProtect prior to accessing anything in your environment? Is that what you're attempting to limit to the US that these users are using commercial VPN solutions to bypass that restriction?

Or are we talking about simply being able to access another public resource behind your PAN that you limit to US addresses? 

[Jaragorn]

In my case the Citrix Netscaler captures (top image) the source IP (ClientIP) and NatIP,  but the PAN doesn't identify the NatIP the same as the Netscaler does for the same session.  In this case, an ExpressVPN VPN session.

  

In every case in which the Netscaler records a session with a different ClientIP/NatIP, they turn out to be a commercial VPN service sessions.  Perhaps if I decrypted the traffic it may pick up the commercial VPN service, but I don't believe it's a best practice for Citrix traffic.

[BPry]

@Jaragorn,

So if you were using GlobalProtect to limit access to NetScaler instead of publishing directly, you could build out HIP checks to ensure that another VPN adapter isn't active on the host to limit that activity. Doesn't sound like you're enforcing GlobalProtect to gain access to NetScaler, so you don't have the HIP check option that would be available to you with an agent.

I think you're left with building automation to identify commercial VPN services being utilized and then blocking identified addresses so that they can't connect anymore. I'd recommend using an EDL so you aren't needing to commit to activate address changes, and then you could either block the EDL as a whole or just to NetScaler so they can't use your Citrix environment when connected to a VPN.

The automation that I would build would look something like this:

• Build out a report for any addresses accessing your Citrix environment (to make it most effective, ensure that log-start is enabled instead of just log-end).
• Query that report through the XML API so that you can grab the source addresses that are connecting.
• Define a way to identify VPN resources based off of the hostname or WHOIS information available. In this example you could search for VPN-Consumer-US as an example. Determine whether you're going to attempt to block just the address, or if you'd rather try and block the IP range returned in the WHOIS record.
• Feed identified addresses into your EDL source so that the firewall can poll them at whatever schedule you have set as a refresh interval. 

Most of my clients who go through the process of identifying things at this level have a policy that their users are not to use consumer VPN services and must only work while in the United States. Of those, the vast majority aren't allowing BYOD endpoints to connect at all which means you'd just use endpoint policy to block access to consumer VPN applications.

In the event that BYOD is actually allowed and they identify this behavior we have the above script running to identify someone breaking policy, and we'll block the source address or range associated with the VPN. The bigger aspect however is not an IT or security aspect, but rather that the employee has violated corporate policy. The vast majority of these institutions have the script disable the account and all associated access as a security response, and the rest of it is handled by their respective HR departments. 

[OtakarKlier]

Hello,

Another solution which I'm sure has already been discussed is to have users VPN into the environment prior to utilizing the Citrix environment. I'm sure there is a lot of pushback with this, however its easier to control the internal environment rather than exposing something directly to the internet, per se.

Regards,

[Jaragorn]

Hello BPry, we use GlobalProtect for VPN access to the C suite only, all others access Citrix, which also sits behind the PAN and uses Duo to perform MFA on the netscalers.

[Jaragorn]

Hello BPry, there is pushback on having user use GP to access Citrix but the more info I have to make a case the better.   The idea of using HIP checks to check for active adapter sessions seems like it would be helpful but I couldn't find anything on it when I last looked at it, and I don't see anything about networking on the GP -> HIP Objects tab (registry setting?).   

Any info you have on that topic would be appreciated!

[Jaragorn]

Completely agree, but you're correct about the pushback.

[OtakarKlier]

Hello,

On the HIP checks, look for stuff that is specific to your environment. Might be tough since they are company machines etc. Another think I always recommend is to use the built-in EDL's to create a security poly to drop the traffic. Along with a Zone Protection profile. However not a guarantee this will work. Not sure if anyone out there is tracking these types of sites, however you could have SIEM alert to something like, alert if users are connecting from the same IP. The find out who owns the IP's and block the entire ASN subnet? Its whack-a-mole, but people might give up after a while?

Regards,

[OtakarKlier]

Hello,

Had another idea, not Palo Alto and there is a cost. Use a secure DNS service and have the agent installed on all machines. Something like OpenDNS. This way when they try to go to one of those sites, its blocked but OpenDNS. This would also help when users do not want to connect to the VPN.

Another option could be to use 'Always-on' vpn. THis way the users may not need to enter additional credentials, but they are one the VPN.

Just some random thoughts.