Archives for category: Firewall

When troubleshooting traffic flows through the Palo Alto NGFW, it can be difficult to see what’s happening. Using the logs from the GUI can help.

An alternative is, to use the command line “show session all filter destination [IP]“. This shows you a filtered view of stateful sessions going through the firewall. It provides information like state, source/destination, translated IP/Port. An example is shown below. (Use the context sensitive help if you need more options)

admin@PA-FW> show session all filter destination

ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
37167 web-browsing ACTIVE FLOW *NS[55927]/trust/6 ([40416])
vsys1[443]/untrust ([443])

Once you have the session ID (in the case above the session ID is 37167), use the command “show session id 37167” to drill down further into the information within that session.

admin@PA-FW> show session id 37167
Session 37167

c2s flow:
 source: [trust]
 proto: 6
 sport: 55927 dport: 443
 state: ACTIVE type: FLOW
 src user: test\robert
 dst user: unknown
 qos node: ethernet1/1, qos member Qid 0
 match src interface: any
 match src address: ('any ',)

s2c flow:
 source: [untrust]
 proto: 6
 sport: 443 dport: 40416
 state: ACTIVE type: FLOW
 src user: unknown
 dst user: test\robert

start time : Fri Jan 26 10:03:53 2018
 timeout : 60 sec
 time to live : 48 sec
 total byte count(c2s) : 1924
 total byte count(s2c) : 5115
 layer7 packet count(c2s) : 14
 layer7 packet count(s2c) : 10
 vsys : vsys1
 application : web-browsing
 rule : Rule 2
 session to be logged at end : True
 session in session ager : True
 session synced from HA peer : False
 address/port translation : source + destination
 nat-rule : NAT-Outside(vsys1)
 layer7 processing : completed
 URL filtering enabled : True
 URL category : Rule 2
 session via syn-cookies : False
 session terminated on host : False
 session traverses tunnel : False
 captive portal session : False
 ingress interface : ethernet1/2
 egress interface : ethernet1/1
 session QoS rule : N/A (class 4)
 tracker stage l7proc : proxy timer expired

As you can see above, the amount of information can be very helpful for troubleshooting. If you suspect a particular session is causing a problem, you can clear with the command “clear session ID 37167



This feature is similar to Cisco IPSLA, in that it tracks the reachability of a destination and can remove static routes based on the ping response.

Simple topology with Palo-Alto connected to the internet and using path monitor on the default route. Internal interface peering OSPF with the core router and redistributing the static route but only when the ping responds.











First create the static route
Network -> Virtual Routers -> (router) -> Static Routes -> Add+

Virtual Router - Static Routes

In this scenario the path monitor will ping the opposite side of the link and Google DNS, both must fail for the condition to be met. Interval and count are default (5 pings 3 seconds apart). Once the pings fail, the route will be removed from the routing table. When the router is able to ping the destination after a failure it waits 2 minutes before re-installing the route, this is default preemptive behaviour and can be changed.

Next create a redistribution profile that redistributes your routes, what I found was that if you redistribute ‘’ that means all routes, if you have other routes you don’t want to redistribute just match them with a lower priority and choose ‘No redist

Network -> Virtual Routers -> (router) -> Redistribution Profile -> Add+

Redistribution Profile

Configure OSPF as you normally would with any other device no difference here the usual attributes must match. Area 0 is the same as Area

Next apply the redistribution profile to OSPF and check ‘Allow Redistribute Default Route‘. You have the option to set external type, metric and tag.

Network -> Virtual Routers -> (router) -> OSPF -> Export Rules -> Add+

Export Rules

The Palo-Alto should have formed neighbors with the core router and be redistributing the default route. This can be seen here. Network -> Virtual Routers -> More Runtime Stats. You can also view the routing table here and the forwarding table along with OSPF neighbors etc.

Run Time Stats

Currently the core router receives the route from the Palo-Alto


Next fail the routing on the internet router to see the impact on the path monitoring. The outcome is, the route is withdrawn (debug ip routing)

Route withdrawn

Path Monitor (down)

On the core device you may have a floating static or default route with a higher metric from a different IGP, waiting to take over in the event of a failure to the Palo-Alto.

When routing is restored you can view the preempted route counting down. After the 2 minutes the route is re-instated.

Preempt hold

That’s it, works great.


IPv4 MTU issues can be hard to spot initially, there is a solution and its called Path MTU Discovery (RFC1191). The RFC describes it as the following “a technique for using the Don’t Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path”

Further to that the RFC states “The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning “fragmentation needed and DF set” (Type 3, code 4)

The unfortunate issue is that the message that’s sent back doesn’t actually say what the MTU is.

A colleague of mines who is a Windows 7 expert, has reliably informed me that by default Windows 7 has PMTUD enabled.

The important point to focus on is the ICMP unreachable (Type 3, code 4). To put this quite simply, if you don’t receive an ICMP message back with the code for fragmentation needed then, your PC will assume that the MTU is fine and continue to send the packets even though somewhere in the path the packets are potentially being dropped.

There can be a number of reasons for this, including firewalls blocking the message, ICMP unreachable disabled on an interface, a transparent host between 2 endpoints (Often done in service provider networks) that has a lower MTU value.

I recently ran into an issue where IP connectivity between 2 sites looked to be fine, ping, traceroute and SSH were all working, but certain applications and protocols were not, most notably HTTPS.

Below I will explain how to spot this issue.

Take a look at the diagram below, i have deliberately used a transparent device as its most likely what you might see in a L3VPN (MPLS) network. The last mile provider provides a layer 2 path (perhaps a L2TPv3) from CE to PE and the underlying hops are hidden from us.  From the service provider perspective the routers are directly connected.

This is perhaps where an MTU issue has occurred. For this scenario I have reduced it quite significantly for effect.


Lets say for example you have a perfectly functioning network where MTU is fine along the path. Initially you can send a ping with 1460bytes and you will get a reply. Lets increase this to something we know is to big (1550bytes). This works great in a perfectly functioning network where you receive an ICMP type 3, you will get the “packet needs to be fragmented but DF set” message.


Now lets try that through our network where the MTU is set lower but the sending device doesn’t know about it.


At first you think its OK because you can ping along the path and get a reply, you try SSH and it works too. Now lets try to ping with different MTU sizes. Remember your PC doesn’t receive the ICMP message this time, so what happens is you get a “request timed out” message.


The reason for that is the packet is being dropped and the ICMP message isn’t being returned. If I ping with an MTU that is lower than the 1000 i get a reply.


Now the question, why would HTTPS not work? well in some cases web applications or your client might set the Do Not Fragement bit in the IP header SYN request. This means the packet should not be fragmented, so when we send this on our network with the bad MTU in the path, the packet is dropped and the sending device never receives the ICMP message. It never knows that it has to reduce the MTU value. The packet capture below shows where the DF bit is set.


I had a look through the RFC2246 for TLS1.0 and it doesn’t specify that the DF bit should be set. It’s most likely a vendor or O/S specific setting, so your observed results may differ from vendor to vendor.


Setting up your ASA for guest wireless is easy, you only need the base licence to do this. First of all you need to know that a VLAN is associated to layer 2 of the OSI model, and when your clients connect to the Guest Wireless VLAN they will be able to route out the VLAN via the ASA firewall. So here’s your topology.


I can hear you ask why there are 2 connections to the firewall well one is your inside corporate interface and the second is your guest wireless interface.

So you’ve already setup your AP either its an autonomous AP or you have this connected to your LAN controller, the reason you need to trunk your AP to the switch is so you can have multiple SSID’s each with its own VLAN assigned. One thing I would mention is make sure your switch has DTP turned off for unused ports, don’t think I need to explain that one do I?

ASA1(config)#interface vlan 3
ASA1(config-if)#nameif Guest
ASA1(config-if)#security-level 50
ASA1(config-if)#ip address
ASA1(config-if)#no forward interface vlan 1
ASA1(config)#interface ethernet 0/2
ASA1(config-if)#switchport access vlan 3

NAT Translation

ASA1(config)#global (outside) 1 interface
ASA1(config)#nat (Guest) 1

I usually assign DHCP address’ from the ASA when setting up guest wireless this way, but you can do it from the LAN controller or the AP itself. Here’s the config for the ASA

ASA1(config)#dhcpd address 192.168.1.x 192.168.1.x Guest_DHCP
ASA1(config)#dhcpd dns
ASA1(config)#dhcpd enable Guest_DHCP

That my friends is all there is to it, your ASA will already have the ACL in there that states “any to any less secure network” which means your guest wireless clients will be able to access the internet and the config line “no forward interface vlan 1″ prevents access to your inside corporate network.

“If you cant see it, it’s not there”