@NorthIdahoTomJones

A bit late, but here is one possible way:

Click Services -> FRR Global/Zebra
Click Route Maps
Click + Add

General Options Name -> choose a name Action -> permit Sequence -> 100 BGP AS Paths AS Path Action -> Set Prepend Match AS Path -> None Set AS List -> The AS you want to prepend Click Save at the bottom of the page

Click Services -> FRR BGP
Click Neighbors
Edit the appropriate neighbor
Peer Filtering

Route Map Filters Outbound Route Map Filter -> Select the route map created above from the drop down list Click Save at the bottom of the page

@Soyokaze Hi,

we are facing the same problem. At the moment we restart FRR after each reboot or power failure to get it recognizing the wireguard interface.

Sometimes it is also necessary after applying settings in the wireguard section.

That really really annoys everyone.

Thanks for your summery

@torstein Um,

I don't use BGP but it works on OSPF, or rather OSPF works over WireGuard. OSPF is normally multicast, so you have to set the links as point-to-point and they'll discover themselves just fine. You don't even need to specify the neirbor's address. It's pretty cool, I think.

As I mentioned, I don't use BGP because I don't know much about it, but as I gather, it works over TCP and directly addresses its neighbors so I see no reason why it wouldn't be possible.

Here are some examples, they for other platforms but you should be able to translate if you understand it though. :)

VyOS' configuration blueprints — https://docs.vyos.io/en/sagitta/configexamples/index.html "BGP works with WireGuard without any special steps so long as the peers are static and the peers have Tunnel Endpoint Next Hop Entries configured." — https://docs.netgate.com/tnsr/en/latest/wireguard/example.html

@michmoor Hi,

so, i just put everything in the 0.0.0.0 area, and rather than having, under firewall/ipsec rules, from * to *, I just need to allow/deny subnet in each location ?

Frank

@michmoor Thanks
was missing only a small thing and now everything work!

That error is likely due to an outdated library. Try:

pkg update pkg install -fy libyang2

Hey all,

I wanted to check in and close off this thread if possible, since it's been a while.

Can I ask to confirm what he current pfSense behaviour is for FRR and if it still is a full restart on each config change, if there is any plans to change this behaviour going forwards? (cc @jimp )

Thank you!

https://redmine.pfsense.org/issues/13575

For pfSense+ 23.09, "FRR 9.0.1 is added and working". I can see it in the package list data but am yet to upgrade.

For CE, it looks like they are targeting 2.7.1.

This is great news - thank you Netgate.

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