@DEHAAS I cannot se this as anything but a bug, thus I have created it as an issue here https://redmine.pfsense.org/issues/14630

OSPF will only advertise networks it sees on the interfaces directly. If OpenVPN is in subnet topology mode (not net30) it may work, more likely to be correct with tap than tun but I'm not certain there.

If you are setup with an ABR style OSPF config (local areas on each end with a 0.0.0.0 backbone on the link between routers) you can setup a summary route entry with an entry that you want to advertise.

The docs have an example like this:

https://docs.netgate.com/pfsense/en/latest/packages/frr/ospf/example.html

@michmoor Thank you for your reply. I have working bgp configuration made in "Raw config" section. But I'd like to configure it using web interface.

The route map looks like that:
route-map map-vpn permit 10
set community 36987:100
set ip next-hop 10.8.0.1

How to set IP address of hext-hop in the web interface? I can't find this field in Next-HOP section...

@Leksandr You need a backbone area - Area 0.

textdump.tar

@n1k friend, I started a little study on top of the FFR, I confess that I am not able to understand the access lists, my environment has VLAN and when configuring the neighbors they receive all the network. Could you give me an example of how you set it up?

Thanks.

Got the same problem.
In my case, there are no errors. The configuration in /var/etc/frr/frr.conf is changed, but the changes are not automatically applied. Only after service restart.

In frr-reload.log only these messages

2023-05-05 05:49:35,113 INFO: Called via "Namespace(input=None, reload=True, test=False, debug=False, log_level='info', stdout=False, pathspace=None, filename='/var/etc/frr/frr.conf', overwrite=False, bindir='/usr/local/bin', confdir='/var/etc/frr', rundir='/var/run/frr', vty_socket=None, daemon='')" 2023-05-05 05:49:35,113 INFO: Loading Config object from file /var/etc/frr/frr.conf 2023-05-05 05:49:35,727 INFO: Loading Config object from vtysh show running 2023-05-05 09:49:40,111 INFO: Called via "Namespace(input=None, reload=True, test=False, debug=False, log_level='info', stdout=False, pathspace=None, filename='/var/etc/frr/frr.conf', overwrite=False, bindir='/usr/local/bin', confdir='/var/etc/frr', rundir='/var/run/frr', vty_socket=None, daemon='')" 2023-05-05 09:49:40,111 INFO: Loading Config object from file /var/etc/frr/frr.conf 2023-05-05 09:49:40,771 INFO: Loading Config object from vtysh show running

By the way, in the test environment, everything works.

2023-05-05 04:41:57,444 INFO: /var/run/frr/reload-Z85C6S.txt content ['interface igc0.50\n ip ospf network broadcast\n', 'router ospf\n area 0.0.0.0 shortcut default\n', 'interface igc0.50\n ip ospf network broadcast\n', 'router ospf\n area 0.0.0.0 shortcut default\n'] 2023-05-05 04:43:50,788 INFO: Called via "Namespace(input=None, reload=True, test=False, debug=False, log_level='info', stdout=False, pathspace=None, filename='/var/etc/frr/frr.conf', overwrite=False, bindir='/usr/local/bin', confdir='/var/etc/frr', rundir='/var/run/frr', vty_socket=None, daemon='')" 2023-05-05 04:43:50,789 INFO: Loading Config object from file /var/etc/frr/frr.conf 2023-05-05 04:43:51,425 INFO: Loading Config object from vtysh show running 2023-05-05 04:43:51,735 INFO: "frr version 7.5.1" cannot be removed 2023-05-05 04:43:51,736 INFO: /var/run/frr/reload-RH67QI.txt content ['interface igc0.50\n ip ospf network broadcast\n', 'interface tun_wg3\n ip ospf hello-interval 1\n', 'router ospf\n area 0.0.0.0 shortcut default\n'] 2023-05-05 04:43:52,043 INFO: Loading Config object from vtysh show running

@bingo600 If im reading this section correctly....

""The DoS condition may be prolonged indefinitely by repeatedly sending malformed packets. The main root cause is the same vulnerable code pattern copied into several functions related to different stages of parsing OPEN messages."

then the only way to be impacted by this is for the attacker to have compromised a bgp speaking system. BGP peers are established typically with defined neighbors in the configuration so you are not getting an OPEN message from an unknown neighbor. The exception to that would be if you have a BGP configuration and accept any connections from any neighbor -- which i do see within an enterprise. But i think that feature isnt even supported on pfsense. I remember seeing a forum post asking for such a feature in FRR.

@derelict Thank you!

I had a hunch about that, but as I also saw this "NSSA Totally Stub Area" and I'm like what the ff—is that one or two things? "Not-So-Stubby-Area Totally Stub Area"

You were right one time because about to configure the virtual link, I realized it's at the other side of an ABR. The ABR already would know about it.

I tried setting up the edge router as a type shortcut ABR, but it would form no adjacencies at all. This was only just now though, I haven't had time to explore; inadvertently I enabled DHCP snooping on two switchports to a hypervisor which it's statically multi-homed itself, but the DHCP had migrated there at some point and it was only a matter of time before leases expired and created chaos.

DHCP issues look a lot like multicast issues. 🤔 "OSPF uses multicast…" of course I went with the worst possible choice.

Thanks again — I can sleep now. *sleeping-standing-up-emoji…-or-something*

@lurick I ended up solving this. It looks like at some point firehol pfBlockerNG list was set to block outbound (which applies to the LAN) and then it recently it was updated to block 224.0.0.0/3 or I did something wrong, either way, blocking the entire multicast address range of course would block OSPF neighbors coming up but not OSPFv3 which is using IPv6 multicast.

Final update: on another firewall (also on 23.01), even after going into each neighbor and selecting none for the map, then deleting the map, I get the same error.

I am leaving one map and that seems to keep the error from appearing.

@jcook-atlas I don't know if you've moved on from this to BGP like someone else suggested, but I think your issue may just be a typo. You have 172.18.2. on one side and 178.18.2. on the other.

@mystique_ OSPF is pretty simple to set up.

Enable it and add the interfaces to area 0 and you're done.

One generally sets interfaces that are to be in the OSPF database that are not intended to communicate with other OSPF routers to passive.

That's generally all that HAS to be done to get the IGP working and exchanging routes.