Using Remotely configured Role Names on a Palo Alto firewall

I’ve previously used a mix of LDAP, RADIUS, and TACACS authentication for administrator access on Palo Alto firewalls, but have never done so without local accounts configured on each device. Since our Palo Alto VM-300s are being turned over to the larger parent company with over 20 admins, it is no longer practical to have individual accounts as we needed to control group policy / admin role centrally on the authentication server.

Still on software version 8.1.18, it was a bit confusing how to do this as there were several outdated docs but there, but eventually I found https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClIxCAK which got me on the right track.

Palo Alto Device Setup

Here’s the steps to do this on the Palo Alto device:

If not done already, create a RADIUS or TACACS server profile
If not done already, create an Authentication Profile
Under Device -> Admin Roles, create a new role.
Create or modify a test admin account, defined locally, by setting it to use that role
After verifying roles work as expected, delete that account.
Under Device -> Setup -> Management Tab -> Authentication Settings, set the Authentication Profile for administrative accounts that aren’t defined locally

RADIUS Server Setup

If not done so already, setup a user group to Admin role name mapping on the authentication server. In RADIUS, this is done by adding vendor-specific attribute (VSA) which maps vendor code 25461 to the Admin Role name for the appropriate group. Use Attribute number 1, format = String, and set the attribute value to the admin role name that was created above. This is similar to how the CheckPoints (vendor code 2620) operate.

Here’s an example using NPS on Windows Server 2012R2

Upon successful authentication, the authentication server will result the role name, and the user should be set to that role.

Cisco ISE (TACACS) Server Setup

The process is fundamentally the same, and can be found here:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMYmCAO

Note the case is not consistent on their group names: they use “Read-Write” and “Read-only”. You can change these to whatever values you want, as long as they’re in sync.

VPN throughput Tests – Palo Alto VM-300 to GCP

I was doing a deep dive read of supported IKEv2 ciphers on GCP native VPNs today and thought I’d setup a quick lab to see which settings would provide best throughput. Lab setup was as follows:

Palo Alto VM-300 on m4.xlarge in us-east-2 (Ohio)
IKEv2 VPN to GCP us-east4 (N. Virginia)
Latency is a steady 13ms round trip time
AWS side test instance is t3.xlarge (4 vCPU / 16 GB RAM)
GCP side test instance is e2-standard-4 (4 vCPU / 16 GB RAM)
Both VMs running Ubuntu Linux 18.04.4
File is 500 MB binary file transfer via SCP

Throughput speeds (in Mbps) using DH Group 14 (2048-bit) PFS:

Encryption / Hash	SHA-512	SHA-256	SHA-1
AES-GCM 256-bit	664	668	672
AES-GCM 128-bit	648	680	704
AES-CBC 256-bit	510	516	616
AES-CBC 192-bit	492	523	624
AES-CBC 128-bit	494	573	658

Average: 604 Mbps

Throughput speeds (in Mbps) using DH Group 5 (1536-bit) PFS:

Encryption / Hash	SHA-512	SHA-256	SHA-1
AES-GCM 256-bit	700	557	571
AES-GCM 128-bit	660	676	616
AES-CBC 256-bit	464	448	656
AES-CBC 192-bit	595	528	464
AES-CBC 128-bit	605	484	587

Average: 574 Mbps

Throughput speeds (in Mbps) using DH Group 2 (1024-bit) PFS:

Encryption / Hash	SHA-512	SHA-256	SHA-1
AES-GCM 256-bit	680	626	635
AES-GCM 128-bit	672	664	680
AES-CBC 256-bit	584	452	664
AES-CBC 192-bit	536	520	664
AES-CBC 128-bit	528	502	656

Average: 608 Mbps

Key Takeaways

GCP will prefer AES-CBC in their negotiations, but AES-GCM provides roughly 25% better throughput. So if throughput is paramount, be sure to have only AES-GCM in the IPSec profile.

If using AES-CBC, SHA-1, while deprecated, is 13% faster than SHA-256 and 25% faster than SHA-512. Since SAs are rebuilt every 3 hours, cracking isn’t as large a concern as in typical SHA-1 use cases.

DH Group does not affect speeds. May as well use the strongest mutually supported value, which is Group 14 (2048-bit). GCP does not support Elliptic Curve (Groups 19-21) so these couldn’t be tested. I would expect faster SA build times, but no change in transfer speeds.

Assuming SHA-256 and Group 14 PFS, this graph summarizes the results:

Using the Palo Alto XML API

Palo Alto version 9 and above has a nice REST-API. For those still on 8, only the older XML-API is available. Here’s a quick rundown on how to use it.

Setup accounts and roles. By default, users with an API key will have full access to the XML API. Here’s a specifically restrictive role:

Once roles are configured, each user or account should obtain a separate API key. This can be done with a simple curl request:

curl -k -X GET \
'https://myfirewall.mydomain.com/api/?type=keygen&user=myusername&password=XXXYYYZZZ1234'

Look for the API key in the XML output between they <key></key> tags.

Download pan-python and unpack it:

tar -xzvf pan-python-0.16.0.tar.gz

Note: this can also be installed as a Python package with pip3 install pan-python. But it requires urllib2, which was replaced with urllib3 in Python3.

Give it a spin:

./pan-python-0.16.0/bin/panxapi.py -h myfirewall.mydomain.com -K "LUFRPT1ZTWcxL0F6RngvNkl2eFdDeS9JMjhDUUlGbTg9ZWhlWEtjUFF3UVU1OEViZlJHWDloLzdvL0s4Zm1kU0MvZ1dMTFpnc2xZcz0=" -x -o "<show><routing><route></route></routing></show>"

This will return XML version of the “show routing route” CLI command.

Palo Alto User Identification and Group Mapping Caveats

I wanted to write a firewall rule to allow only Active Directory group(s) to access a given zone, destination IP, or service. Since the users would be connected directly to the Palo Alto via GlobalProtect, user tracking was already happening. The clients are in source zone “Trust” and user identification was already checked.

I followed the steps in this KB article to configure group mapping but found two major gotchas. In the Authentication Profile, the user domain must be entered. After doing this, users began showing up as domain\username rather than just username. Secondly, in the group mapping configuration, user domain needed to be blank.

I can now write a rule with mydomain\group as the source user.

Common gotchas

In the source zone, make sure the User-ID option is checked.

In Device -> Server Profiles -> LDAP, set the base DN to something at a higher level than all the groups, and set the Bind DN to an account with privileges to lookup group membership.

In Device -> Authentication Profile, set User Domain to the abbreviated AD domain

Under Device -> User Identification -> Group Mapping Settings tab, leave the User Domain field blank.

Useful troubleshooting commands

Check user to IP address mapping table

show user ip-user-mapping all

Get list of LDAP groups

show user group-mapping state all

Check group membership for a certain LDAP group

show user group name mydomain\myGroup

Cisco AnyConnect Client squashing other VPN client routes when there is split tunnel overlap

Consider a VPN client such as Palo Alto GlobalProtect doing split tunneling with an include access route of 10.4.0.0/16, 10.5.0.0/16, and 10.6.0.0/16. The client route table in Windows looks like this, as expected:

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1

The user then connects to a AnyConnect VPN with a split tunnel include of 10.0.0.0/8. Something rather funny happens!

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.4.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2

AnyConnect has created duplicate routes…for routes that don’t even belong to it. But since the metric is a higher value (2 vs. 1) these routes are ignored by Windows. So, no harm no foul I guess?

Different story on Mac though…hmmm

sadf

Palo Alto GlobalProtect Portal login: A valid client certificate is required

Came across this while rolling about Palo Alto GlobalProtect. The knowledge base article suggests installing the cert in the browser’s store, which isn’t really helpful in understanding what the cause or solution was in my case.

There’s also its cousin, which complains about a missing client certificate when connecting to the Gateway:

The problem lies in the Certificate profile configuration. I had understood this to be a way to chain intermediate certs; in fact, that happens automatically when the certificate is upload. Rather, this setting controls the CA for client side certs. If if you’re not using client side certs, the configuration should simply have Certificate Profile left to “None”

Setting admin password for Palo Alto VM in AWS

Like the virtual F5, you’ll initially need to SSH to the virtual appliance and change admin password via CLI:

$ ssh -i ~/.ssh/mykey.pem admin@10.10.10.89

admin@PA-VM> configure
Entering configuration mode
[edit] 
admin@PA-VM# set mgt-config users admin password
Enter password : 
Confirm password :

[edit] 
admin@PA-VM# commit

Commit job 2 is in progress. Use Ctrl+C to return to command prompt

..99%........100%
Configuration committed successfully

Then go back to WebGUI, login as admin, and go from there.

LACP with Palo Alto Firewalls

Today’s task was get LACP working on a Palo Alto, so traffic and fault tolerance could be spread across multiple members of a Cisco 3750X switch stack. The default settings on the Palo Alto surprised me a bit, as I was expecting it to default to active and enable fast timers, but this was easy to set:

Unfortunately during testing, it still took a good minute for failover to work. This is because the standby unit disables interfaces until going active, so there’s a delay of 30-40 seconds for LACP bundling plus an additional 25-50 seconds for Spanning-Tree. Working around Spanning-Tree was easy: just use Edge port aka PortFast. Note it should be enabled at the channel level and ‘trunk’ must be added for it to work on trunk ports:

interface Port-channel4
 description Palo Alto Firewall - LACP
 switchport trunk encapsulation dot1q
 switchport mode trunk
 logging event trunk-status
 logging event bundle-status
 spanning-tree portfast trunk
!

Speeding up LACP took a bit more research. Apparently, only data center grade Cisco switches like the Catalyst 6500 and Nexus line support LACP 1-second fast timers out of the box. The Catalyst 3750 however will support fast timers on the bleeding edge 15.2(4)E train.

Upon testing, the failover downtime due to LACP bundling is now under 10 seconds:

Jul 20 17:58:22 PST: %EC-5-UNBUNDLE: Interface Gi4/1/1 left the port-channel Po31
Jul 20 17:58:22 PST: %EC-5-UNBUNDLE: Interface Gi3/1/1 left the port-channel Po31
Jul 20 17:58:30 PST: %EC-5-BUNDLE: Interface Gi3/1/2 joined port-channel Po32
Jul 20 17:58:32 PST: %EC-5-BUNDLE: Interface Gi4/1/2 joined port-channel Po32