Initial configuration of GlobalProtect

[B.King697629]

Very new (this is my first time playing with it) and having some issues with getting GlobalProtect up and running in a lab environment. Topology is pretty simple:

• ethernet1/1 uses DHCP connecting directly to my upstream Internet carrier - zone: outside.
• ethernet1/2 uses a /30 connecting to my core switch - zone: inside.
• tunnel.1 is my GP-VPN tunnel using IP address of 192.168.100.1 - zone: gp-vpn.

I was largely following this walkthrough: https://www.youtube.com/watch?v=Dj-rjuX9I_E with the only difference being that I'm using local authentication instead of RADIUS.

However, I'm unable to actually reach the GP portal. I also confirmed with running show system software status | match sslvpn-web-server that the process is not actually running (which makes sense as to why I'm unable to hit the portal).

PA Firewall: PA-440

PA Firewall version: 11.2.3

Global Protect Agent: 6.3.2

Global Protect Clientless VPN Version: 98-260 (05/23/23)

Advanced routing is on.

Any suggestions would be greatly appreciated.

[BPry]

@B.King697629,

If you install the agent manually can you get it to connect? You could be running into PAN-259769 which is a known issue with 11.2. I don't have anything readily available for a quick check on 11.2, but the process that I would expect to see running off-hand is sslvpn_ngx or just sslvpn. 

The processes that you'll see running on PAN-OS itself are different then what you would expect compared to what you'll see when looking at the process names in the debug software restart commands. I think you likely found an older article, but if you run a match on just sslvpn you should get a return even if GlobalProtect was and never has been configured. 

[DenovoChris]

To clarify a few things, are you getting a timeout just going to the web portal or some other error? Also, are you trying to connect from the inside or the outside? If you're coming from the inside, make sure you don't have a NAT policy that is messing with your traffic or test from a hotspot/home. DHCP is going to make it impossible to write a no-nat rule.

What do your traffic logs show? If you're coming from the outside, make sure you have logging on the "intrazone default" policy, however that is allow by default.

Really the portal is pretty basic and just allowing SSL from outside to outside once the portal is bound to the interface should be about all you need, baring routing and security policy (I setup a GP firewall in a cloud environment yesterday and forgot my default route, took me longer than I'd care to admit to figure out why I couldn't get there). Also, double check your general internet NAT rule doesn't have source zone as any, that would NAT your outside to outside traffic.