Still a puppy in these photos.
“Aurara, you’re beautifull when you’re dancing”
Pictures taken from Helleneset right outside Bergen, november 2018
A hint of the milky way and northern ligths
a huge panorama stretching from Askøy to Brunestykket, lønnborg.
All pictures taken with Nikon D610 and Tokina 16-28mm F2.8
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 192.168.18.140 --> 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 -> 192.168.18.1 INSIDE (DHCP Server) Ethernet1/3 -> 10.198.100.1 Guest (DHCP Server)
All serviceroutes setup to use Ethernet1/2, 192.168.18.1 (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 192.168.18.1, 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 192.168.18.1)
And you’re good to go!
TIP: Be sure to have the right service routes configured if you’re not using management-interface.
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: https://azure.microsoft.com/nb-no/documentation/articles/vpn-gateway-about-vpn-devices/
“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:
step 7
Since we use static routing we simply route the whole /16 net to the tunnelinterface we created
step 8
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.