OpenConnect client with a Global Protect plugin

Reply
Highlighted
L4 Transporter

OpenConnect client with a Global Protect plugin

Hello,

 

We found that only 1 factor authentication is required when connecting to the VPN using OpenConnect client with a Global Protect plugin, it appears that it bypasses the portal authentication and only requires the gateway authentication. We have X-Auth disabled, and cannot restrict connections by Linux OS. 

 
Currently our portal is configured to authenticate with our RADIUS server, and then the gateway will authenticate using LDAP with our AD server.
 
The problem is using OpenConnect with the GP plugin (https://github.com/dlenski/openconnect) allows users to connect directly to the gateway, thus only requiring AD to authenticate.
 
It doesn't appear we can use both RADIUS and AD authentication on the gateway, so it seems we need to force users to go through the portal first, but I've searched the PAN documentation online and have had trouble finding anything relevant/useful.
 
Can someone please guide us/provide some articles regarding this?
 
Thanks in advance.
L7 Applicator

Re: OpenConnect client with a Global Protect plugin

Sorry @Farzana unable to assist but just curious why you would need both rad and AD auth. Does your rad auth not include username, pin and passcode, ( something you are,have and know) if so then perhaps just using rad for gateway would suffice.

 

i mainly ask as the AD extra auth may do something further down the line that I’m not aware of.

 

 

 

 

L7 Applicator

Re: OpenConnect client with a Global Protect plugin

Hi @Farzana,

 

These are some general guidelines that may help:
- 3rd party IPSec clients are expected to connect to gateway directly using standard IKE/IPSec with xauth
- 3rd party IPSec clients do not have the notion know of what the "Portal" is, as this is something specific to Palo Alto Networks and used by our own GP client
- when GP clients are communicating with GP Portal/Gateway, they are using SSL to exchange relevant information and authenticate; end user data traffic is exchanged either via IPSec tunnel or SSL tunnel (depending on gateway configuration)
- 3rd party client can authenticate using:
(a) Group username/password for IKE phase 1, and auth profile (usually LDAP or RADIUS username/password) in xauth (sometimes called IKE phase 1.5) phase
(b) Using certificate authentication in IKE phase 1 (to use cert auth in phase one, group username/password should be left blank in configurarion), and again auth profile in xauth phase
- 3rd party clients we officially support are named here: https://www.paloaltonetworks.com/documentation/global/compatibility-matrix/globalprotect/what-x-auth... Openconnect is not listed.
- 2FA usually means that we are using 2 different factors to access a signle entity; not using one factor for Portal, and one factor for the gateway
- Portal connection is not always mandatory even when using regular GP client, as we can use "cached" configuration when portal is not available, etc. Gateway is usually something we need to protect better; Portal is serving client configuration, and gateway is the one providing access to internal network resources.

 

Thanks,
Nikola M

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!