OSPF and Firewall Rules
-
This is more of an annoyance rather than a serious bug but it seems that OSPF is blocked unless specifically allowed by a firewall rule on the LAN and this rule must be auto-generated from the firewall log. Any attempt to edit the rule e.g. putting a meaningful description in causes the protocol to revert to TCP and subsequently block OSPF traffic.
As I said it's more of a nuisance than a serious problem but it does mean OpenOSPF requires a lot of fiddling to get working in a satisfactory manner.
I should have said that this is completely different behaviour from 1.2.x which just involves installing the package, adding the interface and configuring the area and then starting the service.
-
The behavior is no different from 1.2.3, you have to allow the OSPF traffic in rules or it gets blocked. We don't have an OSPF protocol setting, just set it to "any" protocol with the appropriate source and/or dest.
-
I beg to differ It is just install package and go with no rule changes required. I built a 1.2.3 system to test after I noticed the behaviour in 2
-
Yeah, pretty sure I experienced the same thing gloom describes. I had to auto generate the fw rules for OSPF on 2.0 too and I don't recall having to do that on 1.2.3.
-
Only if you have rules that would already allow it, or in the case of OpenVPN on 1.2.3, don't have "disable auto-added VPN rules" checked (if you want to duplicate that, add a rule to allow everything on OpenVPN).
-
Sorry but I can't get it to work as you describe. A clean 1.2.3 build with only OpenOSPF installed does accept OSPF multicast traffic from my cisco routers, I don't need to add rules, all the OSPF neighbours appear but on 2Beta AMD build I have to add rules to allow the multicast traffic on 224.0.0.5 and 224.0.0.6 that OSPF uses for AllSPFRouters and AllDRouters address (This is as per the RFC). Failure to do so causes it to show as update pending in the OSPF area and the PFSense box receives no neighbour or routing information.
-
Sorry but I can't get it to work as you describe. A clean 1.2.3 build with only OpenOSPF installed does accept OSPF multicast traffic from my cisco routers, I don't need to add rules, all the OSPF neighbours appear but on 2Beta AMD build I have to add rules to allow the multicast traffic on 224.0.0.5 and 224.0.0.6 that OSPF uses for AllSPFRouters and AllDRouters address (This is as per the RFC). Failure to do so causes it to show as update pending in the OSPF area and the PFSense box receives no neighbour or routing information.
By default, OpenVPN traffic on 1.2.3 is not filtered.
By default, OpenVPN traffic on 2.0 is filtered.
Add rules to the OpenVPN tab or if you assigned the OpenVPN instance as an interface, add rules there. You must allow the traffic, or it will not work.
-
When you say OpenVPN is this a typo in your posts as I'm talking about OpenOSPF which is a different fish altogether.
-
Ah, I read another post in the thread that mentioned OpenVPN so I figured you were using OpenOSPFd over OpenVPN.
So you are only attaching OpenOSPFd to physical interfaces like LAN? Or where is the traffic coming from?
Something in the traffic must not be matching your LAN rules if it's being blocked. On possible explanation may be the overly-permissive "webgui anti-lockout" rule on 1.2.3 was allowing the traffic. In 2.0 it's been limited to only ssh and the GUI ports, whereas before it had allowed all traffic to the LAN IP. Do you get log entries when the traffic is blocked? If so, what are they? (Screencap of the filter log view, or perhaps the raw filter log entries)
-
Yes all the OSPF multicast traffic is logged as blocked which doesn't happen on 1.2.3 but as you said the LAN rule is more generous.
It's not a big problem once you are aware of it the only issue being that you can't alter the rule that gets created when you allow the traffic from the firewall log as any attempt to edit it changes the protocol from OSPF to TCP. While that will still work it's a more open rule than I would like to use. -
OK, I just added OSPF to the protocols drop-down so it should be easier to craft a rule for this in the future. The OSPF package could also be changed to add such a rule behind the scenes.
