Tag: VPN

Posted on

Palo Alto VPN (GlobalProtect)
Part 5 – Rules, Testing, Troubleshooting

Intro

In this 5 Part series I covered all the requirements to configure Palo Alto Network’s GlobalProtect VPN:

1) Authentication, Auth Profiles and testing them.

2) Certificates, Cert Profiles, SSL/TLS Profiles and creating them.

3) Portals, what they do and how to configure them.

4) Gateways, what they do and how to configure them.

This part will cover the security rule required, and a little troubleshooting steps along the way.

Things not Covered

I didn’t cover creating DNS records, as again, these come down to your own DNS provider and whatever tools and portals they offer to manage those.

I don’t cover configuring the interfaces (public facing or internal), I don’t cover the virtual router and routes. All these are assumed to be handled by the administrator reading these guides.

I don’t cover installing the client software, if you have the certificates installed on the client devices (Required), it’s simply navigating to the portal address with a supported browser and downloading the installation packages (.exe for windows).

For giggles, I tested navigating my portal from my phone, it did prompt me for my certificate (the VPN was working well) yet after selecting my certificate I got a connection reset error on my browser and checking the Palo Alto Firewall logs (Monitor tab -> traffic) I indeed saw the Deny traffic and action reset-both action… why this is, even though the application was identified correctly as web-browsing and that was enabled in the rule, it wasn’t being allowed by my rule and instead was being denied by my deny all rule. I”m not sure exactly why this is, however I don’t have intentions of accessing my portal web page anytime soon, so for now I’ll ignore this as I use IPsec XAuth RSA on my android device.

I have also noticed that for some reason with Samsung Android I can’t seem to get this VPN setup to work, from quick google searches people seem to say it’s due to packet fragmentation somehow. I haven’t yet had the chance to look into the nitty gritty of this issue just yet, but when I do it will be it’s own blog post!

I also don’t cover installing the completed certificates onto end devices as again this comes down to the end devices being supported by the administrator configuring Global Protect and is outside the scope of this guide.

The Security Rule

As you can tell pretty simple, anyone from the internet (I could be connecting from anywhere, and my IP address changes on my phone all the time, random access points etc) to my public IP address which hosts my portal and gateway, and the required applications (IKE, ipsec-esp-udp, and the SSL and web-browsing) again I haven’t exactly figured out the portal web-page loading issue just yet.

 

*UPDATE* ensure to add panos-global-protect application type, else only X-auth RSA connection will succeeded, that does not rely on the Global Protect Portals.

Failure to add panos-global-protect applicatin results in end client getting “No Network Available” error on the Global Protect App.

My Phone Config

In my case I do run an Android phone, running : 8.0.0: Kernel 4.4.78

The OS is some H93320g couldn’t find much but this about it…

For the most part I install both my Offline-Root-CA and my Sub-CA certificates on my phone. Which can be found under (General -> Lock Screen & Security -> Encryption & Credentials -> Trusted Credentials (Instead of CA’s who knows?) -> User (Both Should be listed here)

Then Installed the User certificate with the private key, which then shows up under (General -> Lock Screen & Security -> Encryption & Credentials -> User Credentials (Instead of User Certificates?)) The other annoying part is once you have the certificate installed, this area doesn’t allow you to see the certificate details, you can see them under the area mentioned above, but this area…. nope.. :@

Once the certificates are installed, it simply comes down to configuring the VPN settings. (Settings -> Network -> VPN -> BasicVPN -> Click the plus in the upper right hand corner. Then)

Name: Give it a meaningful name

Type: IPSec XAuth RSA

Server Address: The Address defined in Part 3 -> Agents -> External Gateways

IPSec User Cert: The User Certificate you installed and verified above

IPSec CA Certificate: Don’t verify server (Which is probably why I didn’t need the above server address in the gateway certs as a SAN)

IPSec Server Certificate: Receive from server

Then enter a username and password for a user you defined to be allowed per your Authentication Profile you created in Part 1.

You shouldn’t have to define the advanced settings as those should defined to the client from the gateway config we created in Part 4.

Summary

If done correctly you should have a successfully, you should be able to see all the parts play out in both the traffic logs, and the system logs…

System:

Traffic:

That is pretty much it, if you have a failed connection do the usual step by step troubleshooting starting with connectivity, you should be able to see the access attempt from the device in the traffic logs, if they are being blocked by rules, adjust them accordingly.

If you verified all other things, it maybe your chain, or you are enabling extra security like verifying the server certificate than you chain would have to be different then presented here, probably all certificate including the portal and gateway certs being signed by the sub CA completely, then all certs will be trusted by all devices. I’ll admit this isn’t the cleanest setup, but it’s the closest to a bare minimum install of Global Protect using your own internal PKI.

I hope this guide helps someone. 😀

Posted on

Palo Alto VPN (GlobalProtect)
Part 4 – Gateways

Intro

The Gateway is pretty much exactly as it is named, the gateway where you get a virtual connection to tunnel into the network.

Requirements:

1) And Interface with a Public IP address.
2) Certificates (Covered in Part 2)
3) Authentication Profile (Covered in Part 1)

Configuration

On the Palo Alto Firewall go to Network -> GlobalProtect -> Gateway

Under General give it a Name and define the interface in which has your Public IP address. *Note* The IP address can be left as none, this will work fine if your interface gets its IP address via DHCP, if you have static the static IP address should be populated from the drop down and can be selected. The Appearance section allows you to alter the web login portal that can be used to download the GlobalProtect client software.

Under Authentication Select a SSL/TLS Profile which contains the certificate which will secure this portal)

Then click add under Client Authentication and add the Auth Profile which states which users are going to be allowed to authenticate through this portal. Then select a Certificate Profile. (Covered in Part 2)

This is the first section that actually looks different than the portal configurations, under the Agent section the first area is the tunnel settings. This is where you define which tunnel interface (i picked the default, you may need to create additional tunnel interfaces if doing multiple portal/gateway configurations). In my case I was setting up tunnel based IPsec type VPN.

I left all the Timeout Settings as default, then moved onto client settings. Here we define any particular users, what OS they are allowed, and what IP addresses they are to be assigned (basically acts as a dedicated DHCP for the virtual tunnel interface when the VPN is established).

 

Next, under Network Services define the internal DNS server and WINS servers, as well as the DNS suffix users who connect will use, this will allow them to work as if they were locally at work.

In my case I didn’t have to deal with HIP Notifications or the Satellites section. 😀

That’s it for the Gateway, this unfortunately is not enough and we still need to define our Security Rules. Luckily since the Portal utilizes a public facing interfaces, we don’t have to deal with any NAT rules as connections are routed through the virtual tunnels that get created pretty much through the settings we defined in this part. 😀

As you can tell these post are a lot shorter as the hardest parts is building the pre-requisites.

Till Part 5, Cheers!

Posted on

Palo Alto VPN (GlobalProtect)
Part 3 – Portals

Intro

The Portal is pretty much exactly as it is named, the portal where you fist connect to, validate you have the certificate to establish a secure communication to send your credentials over and tell your device what gateway to establish to tunnel connection with.

Requirements:

1) And Interface with a Public IP address.
2) Certificates (Covered in Part 2)
3) Authentication Profile (Covered in Part 1)

Configuration

On the Palo Alto Firewall go to Network -> GlobalProtect -> Portals

Under General give it a Name and define the interface in which has your Public IP address. *Note* The IP address can be left as none, this will work fine if your interface gets its IP address via DHCP, if you have static the static IP address should be populated from the drop down and can be selected. The Appearance section allows you to alter the web login portal that can be used to download the GlobalProtect client software.

Under Authentication Select a SSL/TLS Profile which contains the certificate which will secure this portal)

Then click add under Client Authentication and add the Auth Profile which states which users are going to be allowed to authenticate through this portal.


Under the Agent section is where you define the which users group use which gateways. As well as which CA they use. *NOTE* The address defined as the gateway should created on your external DNS provider. Also it seem it is not required as a SAN on the certificate.

In my case I didn’t have to deal with Satellites section. 😀

That’s it for the Portal, this unfortunately is not enough and we still need to define our gateway as well, which ironically in a simple setup such as in my case and examples as a lot of the same steps.

As you can tell these post are a lot shorter as the hardest parts is building the pre-requisites. I also don’t cover creating your external DNS records as that comes down to your own DNS provider and the tools and services they provide.

Till Part 4, Cheers!

Posted on

Palo Alto VPN (GlobalProtect)
Part 2 – Certificates

Certificates

In my previous post I covered recovering a downed CA, cause it will be needed for this section of the GlobalProtect tutorial.

Step 1) Importing the CA Certs

We need to add all the CA certs that are involved in completing the chain, so this includes, the Offline-Root-Ca, as well as the Sub Ca.

Adding the Sub CA cert:

Device -> Certs -> Import -> Base64 cer file

Step 2) Generating a CSR

Generate a a Sub CA Key for the PA to handle the Gateway certs, afterwards generate a Gateway certificate as well.

Click generate:

Click Generate

export the CSR, for some reason the latest Chrome causes a constant refresh, argggg had to export the CSR via IE, gross….

Navigate to your CA’s signing Web page (the Sub CA in this case), open the CSR in notepad and paste the results, and select Sub CA for the template:

Then save as Base64 type cert, and import back into the PA firewall, if successful will look like this:

Also import Offline-root-ca cert to complete the chain

Step 3) Certificate Profiles

Alright time for Certificate Profiles

Add all the Certs

Step 4) SSL/TLS Profiles

Create a SSL/TLS Profile:

Name it whatever, pick TLS 1.2 as min and max, and select the PA Sub CA we created earlier.

Step 5) Create User Certificate

Step 5.1) Create Template on CA

Then under Cert Templates, right click it, and duplicate

5 Years, i don’t like doing this often

Signature and encryption, check off include symmetric allowed by subject, min key size of 2048 and key is exportable

Along with the default, check off MS RSA and AES, and RSA SChannel

Subject Name, Supply in the Request, it will complain about the security risk, accept them. (Normally you’d create the certificates at the client machines, but in this case I am doint it the “wrong way” by having a global user certificate)

Click Apply.

If you require additional permissions apply them now, by default domain admins have full control, and domain users have enroll rights.

Step 5.2) Generate User CSR

With the Template configured, lets create the User Cert for the VPN, in this case we generate the CSR on the PA, but since we made the key exportable, we can export the certificate with key to be installed on the end device (instead of the CSR being generated on the device and then signed, and the public key being installed on the portal, which is the right way… hopefully I can get that, but the toughest part is generating certificates on phones, have to learn each devices OS on how to do it)

On the PA Device, Certs, Generate

*NOTE* I noticed that with the latest Chrome that when you attempt to export any certificate it just seems to refresh the page, sadly the only work around I have is to use IE… Ugh….

Open the CSR in Notepad, navigate to your Sub CA’s certificate signing page, sign the certificate.

*Secrete enable remote management on IIS Core*

lol, I was wondering why i couldn’t see my Template in the web interface, so I looked up my own very old blog post (3rd one I believe) and I realized I forgot to publish it, like I did the Authentication Session Template. Durrrr, then it kept complaining about https for cert destro (makes sense) but since I had a core subca, I couldn’t connect to the IIS remotely, then I found this, saved my bacon, and followed this to enable HTTPS, Then finally…

then Import it on to the Firewall,

it should look like this

In the next section I’ll cover configuring the Portal and Gateway settings. 😀

Posted on

Palo Alto VPN (GlobalProtect)
Part 1 – Authentication

Hey all,

I’d figure I’d spin up a really quick guide on setting up client type VPN using Palo Alto Firewalls. In this case it will use GlobalProtect, so will require appropriate licenses to work. I won’t exactly cover the license aspect in my blog as I find that stuff a bore, and can leave that for the good ol’ VARs to handle. Anyway let’s get into this.

Authentication

Palo Alto firewalls support a wide range of authentication sources (which is awesome) however, to start my lab utilizes LDAP. There are ways to secure LDAP with certs and TLS for LDAPS however again that is beyond the scope of this blog post, and will stick with plaintext LDAP connection son port 389. (In my case all my servers reside on one hypervisor, thus the chances of the vswitch being man in the middle is highly unlikely ;))

Step 1) Add a Server Profile

So to start on the Palo Alto (My Examples utilize PAN OS 7.1.x, however, 5-6, as well as 8 are very similar) Web interface go to Device -> Server Profiles -> LDAP then click add.

Give the Profile a meaningful name, then click on the add button under server list.

Couple Notes here:

1) The Name doesn’t have to be the server name, just give it a meaninful name, or give it the server name, whatever you choose (it’s not a DNS lookup)

2) I was having some issues with testing the Auth profile (Which will be covered a bit further down in the blog post) and I thought I may have had issues with my LDAP settings, however “During LDAP server configuration, the device automatically pulls the Base DN if the connection is successful. ”

Since I didn’t have LDAPS setup, I had no cert to use, so I had to uncheck “Require SSL/TLS secured connection” only then would the Base DN auto-populate, verifying that my LDAP connection was indeed successful.

Also note in my lab I had a separate NIC dedicated to my domain, which was separate from the usual home network, thus I had to setup a “Service Routes” for LDAP specifically.

I decided to also create a standard domain account and use it for the Bind DN. This may or may not be required.

Now this is where things get a little weird….

According to step 2 from this Palo Alto post you setup the authentication profile.

Step 2) Group Mapping (Optional)

Which is technically the bare minimum, however, I was hoping to have some group filtering at the Auth Profile, in order to do this one has to first setup a “Group Mapping” and followed this to do it:

Device -> User Identification -> Group Mapping

Click Add, Give it a meaningful name, and optionally fill in the domain

Helpful Commands

  • show user group-mapping state all
    Lists all group mappings on the firewall, which shows the Server Profile used and all groups found from it
  • show user group list
    Also lists all groups, but without ordering via the group mapping info
  • show user group name <group name>
    Lists users within the group specified
  • debug user-id refresh group-mapping all
    If new groups or users added to groups in AD, refresh the info on the PA

*Update* anonymous connection won’t error but will not populate groups when creating a group mapping:

If you do not setup a group mapping, you can’t filter by groups in the Authentication Profile, under the “allow list” which from testing might not be a bad thing… you’ll see…

Step 3) Create an Authentication Profile

This is where my results get weird, which I finally discovered was all due to the “allow list” filtering in which I was attempting to use. Let me show you what I mean, using my first authentication profile as an example:

So nothing special, select LDAP, selected my LDAP Server Profile, then click the next tab is it is required “Advanced” tab.

Now if you setup a group mapping as I specified under the option step 2, you will see all the groups in the domain (CN=xxxx,OU=xxxx,DC=xxxx) format. If you didn’t you will get only all (and that is probably a good thing, not exactly sure yet,…)

So in my first case I decided to use my “domain users” as my filter group, as it’s pretty common group and I don’t have many users in it.

Simple, so now we have all the basics to now test it.

Step 4) Testing the Authentication Profile

Test and fail and test and fail, and smash your face in for using group mappings…. (yet to be determined why)… but for now, log in via SSH into the Palo Alto firewall and test it:

What the heck?!?! I swear everything was correct, I also knew I was entering my password correctly and everything. No matter how you change the settings in the Auth Profile nothing works (I double and triple checked proper group membership in AD, and ensured the firewall could see it all “show user group” and “show user group name “CN=domain users,OU=users,DC=zewwy,DC=ca””) until I noticed from the link in this steps title that his simple test was using that “all” group that is used when there is no group mapping defined, or just simple at the top of the list.

So creating a new Authentication Profile not specifying my AD group..

and testing…

BAMMMMMMMM….

And that concludes the Authentication part well at least the dependency, in part 2 I’ll cover the certificates requirements. I currently have a ticket open with Palo ALto as to why the “Allow List” section of the Authentication Profile doesn’t pick up the users in which should be in those account as shown by the “show user group name “CN group name”, so if this commands shows users based on a group, the allow list should be able to validate that as well.

Until Part 2, Adios!

*UPDATE* According to PAN support the Test Authentication *BUG* although he didn’t want to admit it as a bug is claimed to be fixed in PAN OS 8.1.3. I have yet to upgrade some units to this version and verify that claim.

*UPDATE 2* At the time, I wasn’t sure what version I was running, and on my new system, I was now on 8.1.0, and PAN changed the layout to the group mapping area by adding a new tab (User and Group Attributes)

which in 8.1.0 did not auto populate and since Primary Username was the only required field I did enter “sAMAccountName” but I guess it wasn’t good enough and every time I attempted a test it fail.. and it was driving me nuts…

then I noticed something, in this post… even though it was different, and I noticed in my pictures afterwards too, and I had set my profile to other instead of active-directory.

even after that it was still failing!!

and this was even after updating to 8.1.10 after reading my own previous update that it had been patched, so I decided to create my auth profile and group mapping from scratch and that’s when I noticed it had now auto populated the new tab and I didn’t have to intervene and thus it worked now one 8.1.0 and following all the steps as before carefully:

I decided to quickly test to see if they had fixed the problem I had specified before now in 8.1.10:

nope double checking the group mapping:

I’m not sure right at this moment why the list shows in this style fullyqualfied zewwy.ca\user vs NetBIOS style zewwy\user

then I decided to test trying these:

it appears only matching the fully qualified name entered succeeds, I’ll have to play around to see if I can get that cleaned up to be auto filled so a user only needs to enter a username, or maybe this is required, figured a primary domain can be specified so it doesn’t need to be entered all the time….

well apparently I won’t be able to use a users UPN for this, not yet anyway…

*Update 2023* I updated to PAN-OS 10.2.4 and the “bug” still existed, for tested I removed the group mapping, then tested auth again. Test auth against the auth profile with “any” defined still worked, the auth profile that was restricted to the AD group didn’t work no matter how I formatted the user name. This makes me believe the Allow Group requires group mappings to work.

Proudly powered by WordPress