If your not being escalated when your asking I would ask to speak with their manager; additionally bring your SE and your account manager into the mix. In my experiance you won't get good GlobalProtect support until you get escalated. Tier 1 can get really frustrating to deal with at times, especially when they want to commit something while I already have other changes pending or want to make a major adjustment during the middle of the day.
OSPF doesn't get logged as traffic, as it happens outside (or, maybe "below") the scope of the firewall engine. This is all handled in the routing functions, which happen before traffic reaches the firewall engine. However, it does get logged under System, where you can filter on "ospf", to see what it's doing. Monitor tab --> System. And there's CLI commands that can be run to display all kinds of OSPF info.
This tripped us up last week when we implemented our first OSPF setup from scratch, and nothing worked. :) There's a lot of dialogs, sub-dialogs, and checkboxes that need to be filled in correctly before it all starts to work. And multiple different places that interfaces need to be associated with the OSPF stuff. But, the logs are there, and once you figure out where the information is stored in the Virtual Router configuration, it does start to make sense.
I've never used an actual routing protocol before, and I was able to get a PA-200 talking to a PA-3020 via OSPF, distributing it's IPs and subnets successfully across our internal fibre network and across our Telus MPLS links to remote PA firewalls. :)
One thing I've noticed with PA firewalls is that "the normal way" of thinking about firewalls and routing doesn't really apply. But once you wrap your head around "the PA way" of thinking, it all starts to make a lot of sense. We came from a FreeBSD firewall / router setup, with some Linux firewalls mixed in (so all layer 2/3 filtering) and found the PA firewalls to be a pain to work with initially. But, once we moved away from the strict-L3 packet filtering mindset, we figured out how to make the most of the features offered. Now, if only they'd drop the price ... ;) :)
I have to dissagree, I am seeing OSPF traffic in my traffic log, which is why I brought it to the tac attention.
I get that the PA is different, but I would presume that a next gen system, that has all this smarts in it would atleast understand the OSPF protocol.
A session should easily be follow, the OSPF deamon seems to be able to do it.
Having said that, the OSPF network does seem to be stable my adjancy stats show long periods of time.
Where/how are you seeing OSPF entries in the Traffic log? Do you have Security Policies in place to allow OSPF traffic, or something?
All of our PA firewalls are confgured to use OSPF for routing, but none of them have Security Policies for allowing OSPF traffic (with default deny enabled), and none of them show OSPF entries in the Traffic log. The only entries are in the System log.
We're running PanOS 6.1.x, so things may be different in newer versions.
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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!