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.
I actually got it to work, I thought about what you said @MickBall and opted to give that (Radius) a go, but from the RSA Cloud Administration Console (CAC).
In case anyone ever comes across this post:
Here is how you configure the CAC for Radius:
From there, just follow the usual Palo Radius addition.
What this gives you is from :20 through minute 1:15 of this video: https://www.youtube.com/watch?v=765nH8if-9Q
Big thank you to Sean Martin from Palo Tech Support. He scheduled a call with me everyday for like a week and a half until we worked through all the issues.
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.
@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.
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.
@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.
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 )
@BPry I got it!!!
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.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!