Use Palo Alto API and Script to Pull Automated Backup Config Files

Palo Alto has put out a helpful article on this topic, but I wanted to add a few additional details. This is necessary when you don’t have Panorama or some other 3rd party tool that doesn’t already have an integrated solution for pulling backup configs from the firewall.

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

As the article above mentions, the first step is to generate the API key using this format in a browser. Record and maintain this API key once generated.

https://<firewall-ip>/api/?type=keygen&user=<username>&password=<password>

Next, if you are using a Windows machine, download Curl here: https://curl.se/windows/

I extracted this then took the contents and put it in a folder named “Curl” in the C:\ directory. Next, I created a folder for the backup configs named “FirewallBackups” also in the C:\ directory.

Next, I created the following Batch script below. Replace 192.168.1.1 with the firewall management IP and the actual API key. Also, you can change the directory where the backups are stored as well as the filename.

cd c:\Curl\bin\
curl -kG "https://192.168.1.1/api/?type=export&category=configuration&key=API-KEY-HERE" > c:\FirewallBackups\PaloAltoFilename-01_Backup%DATE:~10,4%_%DATE:~4,2%_%DATE:~7,2%_%TIME:~0,2%_%TIME:~3,2%.xml

In this script, it is switching to the directory where the Curl executable is. You can also follow instructions to add Curl to the system path so it runs without having to switch to that specific directory. At the end of the filename, this script will automatically insert the timestamp to differentiate file names and prevent the file from being overwritten each time the backup runs. The formatting around this is necessary because the timestamp by default has the “:” symbol in it which isn’t supported in the Windows filename so it replaces that with “_” instead.

Finally, you can schedule this Batch script to run on a schedule basis using the Windows Scheduler or a third party tool.

Fortigate SNMP VPN Tunnel Listing and Monitoring

This article describes how to list all VPN tunnels using SNMP and monitor the status of individual tunnels.

This shows all VPN tunnel names and their corresponding OIDs to then be able to monitor:


snmpwalk -v2c -c string_here 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3

This will monitor one of the VPNs determined from the first output:

snmpwalk -v2c -c Hotlips1 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3.2.1

For Interface Monitoring, you’ll need to retrieve the SNMP index number matching the actual interface you want to monitor. Run these commands to see the index numbers and match with the interface:

“config system interface”

“show”

Then take the index number and use this base OID:

.1.3.6.1.2.1.2.2.1.8

That will show all of them, pick the interface with the index you want to monitor.

For example, to monitor interface with index 6 use:

.1.3.6.1.2.1.2.2.1.8.6

Display FortiGate Policy Name or Comments in FortiAnalyzer Logs

By default, the FortiGate does not send the Policy Name or Comments from the policies in logs to FortiAnalyzer or any remote logging server. This makes troubleshooting more difficult.

You must turn this setting on manually from the Fortigate CLI:

config log setting 
set log-policy-comment enable
set log-policy-name enable 
end

Temporarily Add Denied Sessions to Session Table to Reduce Resource Utilization and Log Generation

This is an interesting feature available through the Fortigate CLI that I came across.

Below are the commands to enable denied session to be added into the session table:


#config system settings #set ses-denied-traffic enable
#end

For optimum performance, adjust the global block-session-timer:

#config system global 
#set block-session-timer <1-300>  (default = <30>)#end

Here is a link to the Fortinet knowledge base with a good description of what this is:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD46328

Aruba Clearpass and Juniper Switch Integration for 802.1X Authentication and Access List Mapping

This article from Juniper does a fantastic job of explaining Clearpass and Juniper Switch integration so I won’t recreate the wheel here, but I wanted to share one caveat that I experienced with this:

https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-157-aruba-dot1x-mac-configuring.pdf

Here is an example of the Juniper switch filters or Access Control Lists. Notice that the “IT-Admin” name is just the role that Clearpass sends over to the switch once Clearpass completes the role mapping process for a user authentication.

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server from destination-address 198.18.255.75/32
set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server then discard
set firewall family ethernet-switching filter IT-Admin term Allow_All then accept
set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server from destination-address 8.8.4.4/32
set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server then discard
set firewall family ethernet-switching filter SonyLaptop term Allow_All then accept

The only issue I saw was when testing this was when I had created my service, role mappings, etc in Clearpass with a new role, but had not yet created this matching filter/ACL on the Juniper switch side. So, what would happen is Clearpass would show the user authentication and the correct role mapped, but the user wouldn’t have access. I wrongly assumed that the Juniper would assign a default role so that essentially no filter/ACL would match and the user would simply be allowed full access, but that was not the case. Without a specific filter/ACL for that role sent from Clearpass, the user will not have access.

Use Palo Alto Networks Remote Access VPN on Mobile Devices Without Global Protect License or App

It is possible to use the remote access VPN capabilities of a Palo Alto firewall without having a Global Protect license or Global Protect agent (app) on your mobile device. I do want to mention that you get additional capabilities by having the Global Protect license and app such as TAC support, detailed information about the endpoint connecting to the VPN, split tunneling, NAC-type functionality by profiling and enforcing compliance profiles, and more.

This is helpful if you have just a handful of mobile devices where you want the ability to have remote access VPN.

Here is what the configuration looks like to enable this. First you must enable IPSec along with X-Auth support under the Gateway Client Configuration. You set the Group Name and Password and configure the rest of GlobalProtect like you normally would.

On the iOS or Mobile VPN client settings, create a new VPN configuration and use the IPsec/Cisco tab to configure the necessary settings. IPsec and X-Auth must be enabled. The group password field in the Palo Alto is the equivalent of the “secret” field on the iOS VPN client configuration.

This will also work with the native VPN agent on macOS.

Initial Setup Script for FortiAnalyzer/FortiManager

The FortiAnalyzer and FortiManager Admin Guides provides great information, but one thing i’ve found it lacking is a concise, quick method of giving a VM a new management IP address through the console so you can manage it through the GUI.

Admin Guide: https://docs.fortinet.com/document/fortianalyzer/6.2.0/administration-guide/

Here is a quick script you can use for the initial setup after the VM is deployed to get a new management IP setup, default route set, and management protocols enabled:

config system interface
edit port1
set ip 10.10.10.10 255.255.255.0
set allowaccess https ssh
end
config system route
edit 1
set dst 0.0.0.0 0.0.0.0
set device port1
set gateway 10.10.10.1
end

Now you should be able to access FortiAnalyzer or Manager using the GUI with https://10.10.10.10

Cisco vPC Setup and Caveats

This was my first time setting up Cisco vPC between two Nexus 3K switches and I wanted to document some findings the deviated from their documentation a bit.

NXOS: version 7.0(3)I7(6) was used in this environment.

Here is the topology:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/layer2/503_U2_1/b_Cisco_n3k_layer2_config_guide_503_U2_1/b_Cisco_n3k_layer2_config_gd_503_U2_1_chapter_01000.html#concept_692519898AC94234AAE63D401054816A

The above link does a great job explaining the requirements for vPC and what is involved including using LACP. The only real caveat is when creating the Etherchannel for the vPC peer or downstream port-channels I had to follow this order specifically or it would say that the ports were not compatible when I tried to add them to a port-channel using the channel group command. Cisco’s documentation for Etherchannel suggests adding the port-channel interface first then adding the individual ports to the port-channel.

First add the ports to the port-channel then create the port-channel interface:

conf t
int e 1/49
switchport mode trunk
channel-group 100 mode active

int e 1/50
switchport mode trunk
channel-group 100 mode active

exit

int port-channel 100
switchport mode trunk

Here is a full snippet relevant to the vPC config:

Nexus A:

vrf context management
ip route 0.0.0.0/0 10.10.10.1

vpc domain 1
peer-keepalive destination 10.10.10.20 source 10.10.10.10
auto-recovery

interface port-channel1
switchport mode trunk
vpc 1

interface port-channel100
switchport mode trunk
spanning-tree port type network
vpc peer-link

interface Ethernet1/48
switchport mode trunk
channel-group 1 mode active

interface Ethernet1/49
switchport mode trunk
channel-group 100 mode active

interface Ethernet1/50
switchport mode trunk
channel-group 100 mode active

interface mgmt0
vrf member management
ip address 10.10.10.10/24
line console
Nexus B:

vrf context management
ip route 0.0.0.0/0 10.10.10.1

vpc domain 1
peer-keepalive destination 10.10.10.10 source 10.10.10.20
auto-recovery

interface port-channel1
switchport mode trunk
vpc 1

interface port-channel100
switchport mode trunk
spanning-tree port type network
vpc peer-link

interface Ethernet1/48
switchport mode trunk
channel-group 1 mode active

interface Ethernet1/49
switchport mode trunk
channel-group 100 mode active

interface Ethernet1/50
switchport mode trunk
channel-group 100 mode active

interface mgmt0
vrf member management
ip address 10.10.10.20/24
line console
Nexus C:

vrf context management
ip route 0.0.0.0/0 10.10.10.1

interface port-channel1
switchport mode trunk

interface Ethernet1/49
switchport mode trunk
channel-group 1 mode active

interface Ethernet1/50
switchport mode trunk
channel-group 1 mode active

interface mgmt0
vrf member management
ip address 10.10.10.30/24
line console

Use OpenSSL to Convert a PEM Certificate File and a Private Key to PKCS#12 (.pfx .p12) Format

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

* Note: In this case, the certificate file after “-in” is the actual server certificate and the cert file after “-certfile” is the bundled file that you would get from a CA.

* If this is a self-signed cert, leave out the “-certfile” section since there will not be an intermediary or root CA.