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.
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:
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
Average: 604 Mbps
Throughput speeds (in Mbps) using DH Group 5 (1536-bit) PFS:
Encryption / Hash
Average: 574 Mbps
Throughput speeds (in Mbps) using DH Group 2 (1024-bit) PFS:
Encryption / Hash
Average: 608 Mbps
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:
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.
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.
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:
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”
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:
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