Palo Alto Networks firewalls have 2 implicit/default security rules that are always at the end of the policy. In recent PAN-OS versions, they are highlighted in yellow and can be modified. In older PAN-OS versions, they are not visible. In all cases, their behavior can be overridden by adding explicit firewall rules above.
the default intrazone-default rule permits traffic within the same zone, without logging or security profiles.
intrazone means "within the same zone". This rule permits "trust" to "trust" traffic. If you're running OSPF on the inside of your network, and the firewall is participating in OSPF, the source of the OSPF traffic is trust, and the destination is also trust. This traffic matches the intrazone-default rule WITHOUT LOGGING. So if you're running OSPF and not seeing logs, that's why.
If you'd like to see logs for OSPF traffic, you have a few choices:
1.) create an explicit security policy that permits OSPF from trust to trust, with logging.
2.) create an explicit security policy that permits all trust to trust, with logging
3.) modify the implicit/default intrazone policy and enable logging.
The last rule is the interzone-default rule, which means "between different zones". This rule denies all traffic between zones, without logging.
If your 3rd-to-last security rule is "deny any any with logging", that will override both of the implicit/default rules. This breaks OSPF, BGP, IPSEC, SSLVPN, Captive Portal, etc. and anything else that is to/from the same zone. I believe this is the main reason why Palo Alto Networks made those implicit rules visible and editable.
I'd be interested in seeing the logs you're describing.
It might help to think of it this way. The "traffic log" is a log of the packets permitted or denied by the "traffic enforcement module". The only things you'll see here are uninteresting "firewall sessions" that say "OSPF is running between these two systems".
The App-ID definition for OSPF has a built-in timeout of 30 seconds. This means that 30 seconds after not seeing any OSPF traffic, the session is expected to age out.
With an "OSPF allow" security policy, log at session start, and log at session end, here's what you'd expect to see in the traffic log:
The bottom log is the session start log - so there's not "session end reason" yet. At the time the session started, there was 1 packet sent. 30 seconds later, the session ages-out per the App-ID definition mentioned above. In a steady state, OSPF sends periodic updates in intervals from 30 to 60 minutes. You may get more or less logging detail depending on things like broadcast vs p2p, etc.
In the GUI, you can see quite a few statistics for OSPF in the Virtual Routers / Runtime Stats section:
The runtime stats show the current state of all routing protocols (including OSPF), but the system logs mentioned earlier, contain a history of the OSPF processes and state:
Finally, there are also quite a few CLI-based commands to provide additional insight into the OSPF state:
admin@pa0-black_knight(active)> find command keyword ospf show routing route destination <ip/netmask> interface <value> nexthop <ip/netmask> type <static|connect|bgp|ospf|rip> virtual-router <value > count <1-524288> ecmp <yes|no> afi <both|ipv4|ipv6> safi <both|unicast|multicast> show routing protocol redist ospf virtual-router <value> show routing protocol redist ospfv3 virtual-router <value> show routing protocol ospf summary virtual-router <value> show routing protocol ospf area virtual-router <value> show routing protocol ospf interface virtual-router <value> show routing protocol ospf virt-link virtual-router <value> show routing protocol ospf neighbor virtual-router <value> show routing protocol ospf virt-neighbor virtual-router <value> show routing protocol ospf lsdb virtual-router <value> show routing protocol ospf dumplsdb virtual-router <value> show routing protocol ospf graceful-restart virtual-router <value> show routing protocol ospfv3 summary virtual-router <value> show routing protocol ospfv3 area virtual-router <value> show routing protocol ospfv3 interface brief <yes|no> virtual-router <value> show routing protocol ospfv3 virt-link virtual-router <value> show routing protocol ospfv3 neighbor brief <yes|no> virtual-router <value> show routing protocol ospfv3 virt-neighbor brief <yes|no> virtual-router <value> show routing protocol ospfv3 lsdb scope <link-local|area-local|as-local|all> adv-rtr <ip/netmask> area-id <ip/netmask> lsa-id <ip/netmask> hexdump <yes|no> filter-type-area <inter-area-prefix|inter-area-router|intra-area-prefix|network|router|nssa> virtual-router <value> show routing protocol ospfv3 dumplsdb scope <link-local|area-local|as-local|all> adv-rtr <ip/netmask> area-id <ip/netmask> lsa-id <ip/netma sk> hexdump <yes|no> filter-type-area <inter-area-prefix|inter-area-router|intra-area-prefix|network|router|nssa> virtual-router <value> show routing protocol ospfv3 graceful-restart virtual-router <value> debug device-server dump idmgr type ospfv3-virtual-link id <1-4095> debug device-server dump idmgr type ospfv3-virtual-link name <value> debug device-server dump idmgr type ospfv3-virtual-link all debug lpmgrd dump idmgr type ospfv3-virtual-link id <1-4095> debug lpmgrd dump idmgr type ospfv3-virtual-link name <value> debug lpmgrd dump idmgr type ospfv3-virtual-link all debug routing pcap ospf on virtualrouter <value> debug routing pcap ospf off debug routing pcap ospf delete debug routing pcap ospf view debug routing pcap ospfv3 on virtualrouter <value> debug routing pcap ospfv3 off debug routing pcap ospfv3 delete debug routing pcap ospfv3 view admin@pa0-black_knight(active)>
So, if you're looking for detail on how OSPF is working, the system logs, virtual router stats, and CLI commands are your best bet.
Hopefully that helps clear up some of the confusion. I'd be happy to look at your OSPF traffic logs if this doesn't clear things up.
