GlobalProtect setup frustration

[Shawverr]

Hello -

Originally, I was going to setup GP with RSA MFA using this document: "RSA SECURID® ACCESS Implementation Guide Palo Alto Networks Next Gen Firewall 8.0"

It is written by RSA and is woefully lacking in detail and after seven hours on the phone with Palo support I decided to abandon that idea for now.

At this point I'd just like to get GP working in any capacity, but I can't seem to find any documentation that speak to what I need.  I understand that everyone's cirumstances are different and documentation would be tough to write for every unique situation.  That's why I'm hoping someone is willing to get out the coloring book and crayons to help walk me though this.

I'd like to have an external only VPN (just about every Google search come up with either Internal only or internal/external combo setups). Portal and gateway on same device.

I'm fairly certain that my main issue is with step one, the configuration of the Interface.  I'm trying to follow this: https://docs.paloaltonetworks.com/globalprotect/8-0/globalprotect-admin/get-started/create-interface... but clearly not having much luck.

Ethernet Internet setup like this:

Interface  Type  Mgt Profile   IP Address    VR   Security Zone

eth1/1      L3      Allow-ping   Routable.10/24   vr1   Outside

I have another routable.20/32 for GP.

What's the best way to get started.  Remember, coloring book and crayons.  You're not going to offend me.

[BPry]

@Shawverr,

So if you don't want to utilize your existing untrust (Outside) interface IP for this, and instead utilize a completely seperate address for your GP portal and gateway configuration, you would want to look at creating a loopback interface. Before you go down that route, can I ask why you don't just utilize the IP address already present on your untrust interface? If you are going to put the portal and gateway on the same address and not utilize a seperate interface for GP traffic, there really isn't a point in creating a completely seperate address for this. 

As for an external only configuration, it isn't really touched on because it doesn't need to be. There isn't anything special you have to do, and most people actually run into more trouble configuring internal portals. You'll simply publish an external DNS record pointing towards whatever address you utilize, and then ensure that your internal users either can't resolve the portal address while on your internal network or are denied from connecting to the portal address while working from the internal network. You could also utilize internal host detection so that GP actually knows when it isn't needed to tunnel traffic back and not have to worry about it one way or another. 

[Shawverr]

@BPry Thanks for your reply.  The reason I don't want to use utilize the IP address already present on my untrusted interface is because in the documentation: https://docs.paloaltonetworks.com/globalprotect/9-0/globalprotect-admin/get-started/create-interface... it states, "For added security and better visibility, you can create a separate zone, such as corp-vpn", so that's what I'm trying to do.

It could be just me being paranoid, but it feels wonky to have GP on my main Interface and not in a separate zone.  

As for the loopback, I got nothing on how to make that happen.........

[BPry]

@Shawverr 

I don't think your grasping how the traffic flow in GlobalProtect actually works, and you completely missed where that zone statement in the configuration note comes into play 😉

So let's start with your zone question. The zone of your Portal and Gateway will either be your untrust zone or a DMZ zone. 

Now the tunnel interface that gets associated with the clients is what the configuration note is talking about. While you can assign the tunnel interface in your Trust zone, I 100% wouldn't recommend it. That tunnel interface should be assigned to a zone specific to VPN clients, and then security entries would be built out actually allowing traffic to/from your GlobalProtect clients.

It might be easier to view the flow like this. The Portal provides the basic configuration and authorization of the GlobalProtect client. The client will then be passed off to the Gateway and that gateway assigns the client everything it needs to communicate and what it's allowed to communicate with. All of the traffic from the client to the gateway will be passed through the tunnel interface you created that you've assigned to a "GlobalProtect" zone, and your security policies get analyzed to see if that traffic is allowed to pass. That's an oversimplification, but it should provide you a rough flow. 

[Shawverr]

@BPry Thanks again, I did say coloring book and crayons.  The one thing I am sure is just how much I don't understand, LOL.

[Shawverr]

@BPry So I'm just going to with a really basic configuration.  I can now get the GlobalProtect Portal to come up over the Internet, but can't login.  I've been on the phone with support about this and they can't figure out why either.

What we don't get is why under "Session End Reason" I sometimes get (sometimes not) "decrypt-error" when I'm not set up to do decryption anywhere.

[Mick_Ball]

What authentication method are you using for GP.

looking in the palo system logs may help with auth failures.

[BPry]

@Shawverr,

Do you trust the certificate you are using on the Portal/Gateway on the machine that you are attempting to utilize for this or not? By default, the firewall does decrypt some GlobalProtect traffic. If any auth issues are actually taking place they'll be logged in the system logs, you can filter for them with the query ( subtype eq globalprotect ) 

[Shawverr]

@BPry @Mick_Ball The System log shows "'GlobalProtect portal user authentication failed. Login from: xx.xx.xx.xx, Source region: US, User name: xxxxxx, Client OS version: , Reason: Authentication failed: , Auth type: profile.' 

In Chrome I do have the red "Not secure".

[Shawverr]

@BPry I got it!!!

Network<GlobalProtectPortals<portal-config>Authentication<client-authentication-config<OS

We had "Windows" selected. I set that to "Any" and it works. I tried setting it to "WindowsUWP" and it still didn't work, but set to "Any" and now I can get to the download client page.

Thoughts? Still a long way to go, but finally got past that part! I do appreciate all you guys help with this.

[Shawverr]

@BPry Ok, next problem.  I can get connected to the Gateway and into my network with an IP from the pool range.  But I can't get to the Internet while connected to the VPN.  I think it's because the PANGP Virtual Adapter has an IP and DNS settings, but no default gateway listed.  I can't seem to figure out where to add that???

[Mick_Ball]

@Shawverr , PanGP does not have or require a default gateway, default gateways are only required for last resort unknown networks, the system knows all routes are via the VPN so no gateway is required.

is your tunnel interface associated with a virtual router ? Also... from VPN zone to external or untrusted zone will be classed as in intrazone and not a interzone so you may require a security policy to allow interwebby stuff.

for diagnostics add a deny all policy at the end of your policies and log session start. Then enter your PanGP address in the traffic filter to see if it’s not being allowed in other policies.

[BPry]

@Shawverr ,

Just because it catches a lot of people, ensure that you actually have security policies and a NAT policy allowing the GlobalProtect traffic outbound through  your untrust interface. Nine times out of ten, that's the issue when people can't browse when connected to GlobalProtect. 

[Shawverr]

@BPry @Mick_Ball That was it guys!  Thanks again!  On to HIPS!!!

[Shawverr]

HIP Object > Custom Checks > Process List > What the heck do I got to put in there to make it work?