PfSense UI Not Updating frr.conf

JamieGB

Guys this shouldn't be a difficult question. If nobody on this forum can tell me how to remove all traces of FRR and start again, can someone at least point me to the developer that can?

This isn't funny. I've approved purchase for Netgate as out on prem and cloud firewall solution and this question must have a simple answer.

My next step will be to remove all Netgates from my international hybrid VWAN.

pete35

@jamiegb this is a forum only, you should contact https://www.netgate.com/support

JamieGB

@pete35 Appreciate that but this is the CE so AFAIK no support.

JamieGB

OK well I managed to figure it out myself.

First off, when you configure FRR or any of its subcomponents, you should note exactly which order you configured every component. When you want to, for example, delete a route map which is associated with a BGP Peer, the UI becomes divorced with the config file. The UI does not properly remove relationships between the two components (or if there's more links) and the config file is left in an unmanageable state (from the UI perspective).

To fix this issue:

Uninstall the frr package
SSH to PfSense and enter BSD shell (option 8)
Locate all residual frr files left behind (no removed from package removal) by running find / -name frr and find / regex '.*frr.*'
Delete all the files and folders related to frr. In my case, there is nothing else in the OS which matches the name frr so delete all you find unless you know something is not related to the frr module. To remove directories add the -r switch to rm, eg rm -s /var/run/frr
Download a new backup of PfSense
Open your .xml configuration file in your favorite XML editor (I use Notepad++)
Search for the term <frr
You will find all the PfSense configuration left behind when uninstalling the package should really remove it.
Delete out all <frr.... elements / sections of XML
Restore your backup to PfSense
Reinstall FRR

There you go. Clean install of FRR. You're welcome.

Schannes

I had the same problem. I was able to solve the problem, with clearing the "SAVED frr.conf" field under Services --> FRR --> Global Settings --> Raw Config.
After clearing the field, it was possible again, to use the GUI to configure frr.

michmoor

@schannes The documentation is not entirely clear but you are correct. If the config is saved than any GUI elements you set are not saved. You have to clear it first. Its wonky.

orachimary

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

netblues

@Schannes said in PfSense UI Not Updating frr.conf:

I had the same problem. I was able to solve the problem, with clearing the "SAVED frr.conf" field under Services --> FRR --> Global Settings --> Raw Config.
After clearing the field, it was possible again, to use the GUI to configure frr.

I really want to stress that this is the ONLY feasible way to get frr config and web gui to work again.

And while we are at it I would like to request an addition to the frr ospf menu's

What is needed is to produce the line in bold
interface tun_wg0
ip ospf network point-to-multipoint non-broadcast
ip ospf area 0

This is supported by frr (tested in 25.11.1 and 26.03rc) and is required for ospf over wireguard tunnels
on a single spoke , for hub and spoke setups.

You also need to specify the neighbor by ip.

The reason is that ospf wants multicast, (and works if you add 224.0.0.0/4) on the hub, BUT it will only work for the last spoke, since this is how wireguard operates.

The setting above solves it, but since it is not on the menu, you need to change it by hand , which then gets the configuration out of sync, and one have to do chores described above to get it to synce, and THEN change the line to ip ospf network point-to-multipoint non-broadcast

Hell breaks loose.!!

ps. I would opt for bgp instead of ospf for wireguard tunnels, but this will be another thread!

babak

@netblues Thanks for pointing this out. @netgate can you please update the frr package so we can select P2MP NBMA network types for WG interfaces? Thanks!

babak

@netblues thanks for working this out. I filed this issue in redmine and opened a pull request for the code. Applied it to 7 firewalls with 26.03.1, works flawlessly now. Adjacency after reconnection of a spoke or the hub takes a few seconds now
https://redmine.pfsense.org/issues/16978