R82.10 Upgrade - OSPF Gotcha

[CaseyB]

Hey Check Mates,

I recently upgraded a 3920 appliance from R82.10 Build 271 JHF-22 to the recently released R82.10 GA Build 464. After the upgrade completed successfully, the appliance did not recover successfully from the reboot. I was able to console into the appliance and discovered the issue and everything made sense.

After the upgrade the appliance was using a default policy and was attempting to contact the SMS to retrieve the proper policy; however, it could not do this because OSPF would not establish. OSPF does not establish unless you have a defined rule (sk39960 ). Creating a temporary static route to the SMS quickly resolved my issue as the policy installed and OSPF established.

Now the reason for my post, why is this a thing? As in, why do I have to create a firewall rule to make OSPF work? The initial configuration is all performed in Gaia, and even when the connection comes up the traffic becomes an "Implied Rule" anyway.

The firewall allows random peers to try and establish IPsec tunnels via Implied Rules, so I do not understand the reason why OSPF connections can't be allowed as well.

[the_rock]

Wow...thanks a lot for sharing that @CaseyB 

[Chris_Atkinson]

This somewhat depends on your user configurable choice of global properties, others might not select the same options... 

[CaseyB]

Thanks @Chris_Atkinson, are you able to elaborate on that? Nothing jumps out at me within Global Properties, unless I am not looking at the right terms.

[Chris_Atkinson]

An example might be: "Accept outgoing packets originating from Gateway"

[CaseyB]

Are you suggesting there is a way for OSPF connections to work without firewall rules?

[the_rock]

Personally, just my own experience, I could never get either bgp or ospf working even with that setting enabled, always needed proper routes/rules. Well, lets say rules, since routes would be dynamically generated.

[Chris_Atkinson]

I'm explaining examples of the implied rules reference from your earlier post. 

[PhoneBoy]

After the gateway is upgraded, the last installed policy is wiped because it (typically) needs to be recompiled for the new version.
This means the gateway will fetch the policy from management.
Until it does, the defaultfilter/initialpolicy applies, which definitely does NOT permit OSPF.
Since the gateway couldn't fetch the policy from management due to a lack of receiving a route, the gateway remained in defaultfilter/initialpolicy state.

I suggest keeping that static route in place for future upgrades.
Meanwhile, I think it's safe to remove the specific OSPF rule.

[the_rock]

Im glad you mentioned that @PhoneBoy . I cant speak for anyone else, but my personal experience with major upgrades and policy after rbeoot is, lets just say, 50-50. Sometimes it would load right policy, but then half the time, it would not. Not really sure if there is a specific file/setting that controls that, but thats why, just to be on the safe side, I always ask customers to have someone on site to be able to console it, just in case. I recall oince during Covid, poor guy had to drive to the hospital, luckily was only 10 mins drive, but then we realized defaultfilter policy was loaded. never had that happen except that one time. Either it loads right policy, or initial.