GlobalProtect Portal require :443

[Kevin-Ng]

Hi All,

I have an issue where we need to input <firewall IP Address>:443 in order to connect. But some of my users does not require the :443 to connect to the VPN.

Screenshot as shown below,

Any way that i dont even require :443 to be connected to the VPN?

[Brandon_Wertz]

---

@Kevin-Ng wrote:

Hi All,

I have an issue where we need to input <firewall IP Address>:443 in order to connect. But some of my users does not require the :443 to connect to the VPN.

Screenshot as shown below,

Any way that i dont even require :443 to be connected to the VPN?

---

Why are you defining the port in your portal config?  You shouldn't need to.  Using tcp port 443 is a part of the normal inherent configuration of the Global Protect VPN service.  You should only be putting in the resolvable FQDN of your portal.  Natively the connection will use tcp/443 or if configuration in your config IPSec as a primary option.

Also review your security policy and make sure you aren't blocking the tcp/443 connection for some of these users.

[Kevin-Ng]

Hi @Brandon_Wertz , reason why is because when our user is using without :443 in the portal, we have no issues but after a period of time, they have issue connecting. So we tried our ways, and we add in the :443 onto the portal (it solved the issue).

We think it might be due to the caching, so i tried signing out, clear browser cache and close the globalprotect portal and re sign in again and it fixed our issue.

But this is not a permanent fix, it will occur again so want to check if what is causing this connectivity issue?

[Brandon_Wertz]

I don't know.  I was running 6.0.4 with just machine cert auth and my company didn't have any issues.  Now we're running 6.0.10 on Prisma Access with SAML auth for user, still with machine cert, and in general we have no issues with users randomly getting disconnected.

I would check the things I had mentioned with security policy.  Also look into your GP app config values and see if there's a timeout setting, or some other connection setting which isn't right.

[BPry]

@Kevin-Ng,

You don't mention what version of GlobalProtect this is being seen on, what version have you encountered this issue with? When you say that you don't run into issues with some users but you do with others, what's the actual counts here? Is it that one user is running into issues but nobody else is, or is it 50% of staff is running into issues?

When you encounter the issue with a user what troubleshooting are you doing? Do you see traffic being denied from their public IP, do you see the connection attempt being made at all? What do you see in the PanGPS logs on the client?

[Brandon_Wertz]

---

@BPry wrote:

@Kevin-Ng,

You don't mention what version of GlobalProtect this is being seen on, what version have you encountered this issue with? When you say that you don't run into issues with some users but you do with others, what's the actual counts here? Is it that one user is running into issues but nobody else is, or is it 50% of staff is running into issues?

When you encounter the issue with a user what troubleshooting are you doing? Do you see traffic being denied from their public IP, do you see the connection attempt being made at all? What do you see in the PanGPS logs on the client?

---

Some good points.  I noticed the old UI of the GP client.  It would have to be something under 6.X.  Unless he's running something other than 5.1 the code isn't even supported.  It might be worth upgrading the GP client version to a 6.X version.  For us 6.0.10 is stable, not sure if that would work in the OPs enviornment:

[Kevin-Ng]

Hi, yes we are using 5.1 now. We will try to reinstall to 6.0.10 and test it out.