@SBTech eBGP to iBGP advertisement is handled automatically so your peer 1 would receive the routes that peer 2 is receiving from its eBGP peer.
As far as a preference on outgoing flows, typically local-pref handles that. Weight can be used as well but its not communicated to other peers. So if you set weight at location 1, location 2 could still prefer its outgoing link so its best to use local-pref so that can be communicated within your AS.

Wanted to come back to this topic and say that multipath works very well.

I got two IPsec VPN tunnels running eBGP with ecmp set up.
My iperf test is below
My WAN is 500/500Mbps.
OCITunnel1 and2 are IPsec.
As you can see an iperf with 100 simultaneous connections out the LAN is able to be split up quite nicely across both Tunnels pretty evenly.

9be4c18e-46d2-4326-9e2a-5910f2155c6f-image.png

ded9569d-2541-47c4-b1b9-e074a9187f55-image.png

I hope this is not an issue any more for you @JeGr. I just want to contribute and/or document a minimalistic solution to the original problem: several undesired /32 networks redistributing from the kernel to the routing protocol.
This solution prevent the propagation of any routes to hosts or /32 prefixes or 255.255.255.255 netmasks defined within the GUI, and some routes created automatically by PFSense, such as the Gateway monitoring addresses, VPN remote gateways, etc.

Create a prefix list: permit 0.0.0.0/0 and maximum prefix of 31.
Screenshot 2023-09-15 at 20.18.30.png Create a route map: just permit the previous prefix list.
Screenshot 2023-09-15 at 20.40.02.png Apply that route map to the kernel redistribution in the routing protocol settings(OSPF in my case).
Screenshot 2023-09-15 at 20.41.48.png

After making all the changes in the pfsense gui (not in the raw config) the "Running frr.conf" in the Raw config tab should look like this:

router ospf !.. !.. redistribute kernel route-map deny_host_routes !.. !.. ip prefix-list deny_host_routes seq 10 permit 0.0.0.0/0 le 31 ! route-map deny_host_routes permit 10 match ip address prefix-list deny_host_routes !

@jimp oh. ok, the Name needs to be numeric. I thought it was an issue witht he sequence numbers. In my previous config I had a name of "Block_Ext" to prevent my external routes from being distributed internally, so it should be a "Zebra ACL" rather than a "Standard ACL".

Did you get a chance to look into why an upgrade broke my FRR routing config? I can upload a sanitized routing config if you need.

thanks.

@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.