All posts by raymond

Using DHCP on PAN device as User-ID, based on device-name


If you’re using DHCP on a PAN device, and want to get a simple way to identify users machines / phone based on device names, you can do so easylie with syslog.

This setup will convert this logline from DHCP:

DHCP lease started ip --> mac 34:02:86:XX:XX:XX - hostname PCNO00198, interface ethernet1/2

To This:

This works from 8.0.0 and up.

My setup:

Ethernet1/1 -> x.x.x.x    Untrust

Ethernet1/2 -> INSIDE (DHCP Server)

Ethernet1/3 -> Guest (DHCP Server)

All serviceroutes setup to use Ethernet1/2, (since I don’t use the dedicated managementport. User Identification ACL has to be enabled for the Zone you want to monitor:



Step 1:

Under Device, Server Profiles, and Syslog. Create a syslog profile that forward logs UDP port 514 to your own devices interface ip.

Step 2: Then, go to Logsettings And create a new Log Setting-System, add (eventid eq lease-start) in filter, and the syslogprofile you created in step 1.

Step 3:

Create a syslogfilter. Go to User Identification, Usermapping, then Palo Alto Networks User-ID Agent Setup, then Syslogfilter, ADD, name it something like PA-DHCP, use Regex Identifiser,

Event Regex: DHCP\ lease\ started

Username Regex: hostname ([a-zA-Z0-9\_\[\]\-]+)

Address Regex: ip ([A-F0-9a-f:.]+)


Step 4:

Under User Identification, and new Server Monitoring (User Identification Monitored Server), Enabled, Type Syslog Sender, and ip of sender (in my case, because of service routes), Connection Type: UDP , and the Syslog Filter you created in step 3

Step 5:

Allow the Interface to be used as User ID syslog listener-UDP. Go to Network, then Network Profiles, and Interface Mgmt. Create a interface Management profile, and allow User-ID Syslog Listener-UDP.

Attach this profile to the interface (in my case the Ethernet1/2

And you’re good to go!


TIP: Be sure to have the right service routes configured if you’re not using management-interface.



Setting up IKEv2 Azure to Palo Alto Networks Firewall

So, lately I’ve setup a lot of vpn tunnels to Azure. With different results. Seems to me that it’s easy to setup the vpn itself, but when it comes to getting the vpn to maintain up and stable you have to tweek back and forth a bit. But heres a example that seems to be working excellent.

Scenario: Two locations, >7 local subnets, one BIG azure subnet.

IKEv2 static routing or policy based as Microsoft calls it:

“Static Routing = Policy-based

Dynamic Routing = Route-based

Palo Alto PA500, using software PANos 7.1.2



Azureside setup as IKEv2 policy based, routing each spesific net to each location (gw), seperate PSK keys for each site.

Step 1, create tunnel interface, assign interface to correct vr and sec zone


Step 2 create IP sec tunnel

bind to tunnel, create new IKE gateway


Step 3,

Setup IKEv2 only mode, bind to interface . Static ip for Azure GW, and preshared key (provided by azure setup)


step 4

I found out that not enabling passive mode worked best for this VPN.

Create new IKE Crypto profile,


Step 5

Azure allows a lot of IKE ciphers, but this one seems to be stable

DHgroup 2, AES-256-cbc, SHA1, keylife 28800 secs


Step 6 Create IPsec crypto profile

Here’s where it gets interesting, according to the samples you should use ESP DHgrp2 AES-252cbc and sha1

And that works. For a while… then the tunnel goes down and never comes up again by itself.

Using this setup

ESP, NO-PFS, aes-256cbc,3des,aes-128-cbc, sha1 and lifetime 3600secs

seems to work the best.


Then the result should look something like this:

PAN sec rules

step 7

Since we use static routing we  simply route the whole /16 net to the tunnelinterface we created


step 8

Create rules to match the traffic (Yes i know this rule is an any-any-rule, but i used that for testing, and migration tool afterwards to convert to lay 7 rules.)PAN

And boom the vpn is up and running

A recommended troubleshooting command if you need it

tail follow yes mp-log ikemgr.log

Provides a good realtime view of the ipsec tunnel. That’s how i found out what was going wrong with the intial setup using the samples provided by azure. The error i got was that the tunnel had missing KE. (proxy id or in this case ciphers and no-fps)


Using  the same setup on both locations worked perfectly.