Bug #14489
open
FRR Needs VPN Linkup Initialization Detection
0%
Description
Hi,
FRR is currently started before completing Wireguard tunnels initialization:
[FRR startup]
2023-06-17 18:48:30 ,754 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='')"
[Wireguard initialization]
Jun 17 18:48:31 fw1 kernel: wg2: changing name to 'tun_wg2'
Jun 17 18:48:31 fw1 kernel: tun_wg2: link state changed to UP
Note that Wireguard starts 1 second after FRR, but in FRR there are already references to the renamed interfaces, which doesn't exist until 1 second later. To workaround this I have to manually restart FRR after each boot.
Just delaying the startup of FRR until Wireguard is fully set up would be enough.
Regards
Updated by Tjabo T. almost 2 years ago
Spike R.D. wrote:
Hi,
FRR is currently started before completing Wireguard tunnels initialization:
[FRR startup]
2023-06-17 18:48:30 ,754 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='')"[Wireguard initialization]
Jun 17 18:48:31 fw1 kernel: wg2: changing name to 'tun_wg2'
Jun 17 18:48:31 fw1 kernel: tun_wg2: link state changed to UPNote that Wireguard starts 1 second after FRR, but in FRR there are already references to the renamed interfaces, which doesn't exist until 1 second later. To workaround this I have to manually restart FRR after each boot.
Just delaying the startup of FRR until Wireguard is fully set up would be enough.
Regards
+1 (fully patched system, same behavior and fix request)
Updated by Andrew Collings over 1 year ago
I had the same issue so I wrote a system patch to sleep for 30 seconds at the beginning of frr.inc. It's janky, but it works for me. If anyone else wants to use it until there's a more permanent solution the patch and installation instructions are available at https://github.com/alc5440/pfSense-frr-delay/tree/main
Updated by
Updated by Kris Phillips 10 months ago
- Status changed from New to Confirmed
- Affected Version changed from 2.7.x to 2.8.x
- Affected Plus Version set to 25.07
Updating affected version for both CE and Plus and marking Confirmed, as I've also seen this behavior.
Rather than adding an arbitrary "delay" into FRR, which while it may work is a hacky workaround, we should add detection to verify VPN processes are fully started before attempting connections to neighbors that utilize VPN links, as this could also greatly help IPSec VTI tunnels that can have similar behavior.
Updated by Kris Phillips 10 months ago
- Subject changed from FRR needs delayed startup to FRR Needs VPN Linkup Initialization Detection
Updating title
Updated by Reggie Walters 9 months ago
I'm also having this issue. I have to restart the FRR service after rebooting the routers otherwise BGP will not come up. Routing is the primary purpose of my routers, so if there is any way I can help test patches, I'm willing.
Updated by Arnie Singh 19 days ago
I'm hitting this issue too with IPSEC. I have to log in to the multiple sites after a reboot and manually force the connection reset for the connection to re-establish. I tried the patch too and increased the sleep time to 180 but that still didn't fix it for me.