Project

General

Profile

Actions

Bug #13043

open

OSPF over Wireguard interface doesn't populate neighbors after reboot

Added by Adam Goldberg almost 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
WireGuard
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:

Description

Running pfSense Plus 22.02 and the latest Wireguard (0.1.6_1) and FRR (1.1.1_6 / 7.5.1_3) packages. OSPF works as expected when a Wireguard peer over a transit network is specified in non-broadcast mode.

However after a reboot, OSPF does not start on the Wireguard tun interface and no neighbors are populated. Restarting FRR ospfd and FRR zebra does not resolve.

The only resolution is making a change to the interface in configuration (example: checking or unchecking Accept Filter "Prevent routes for this interface subnet or IP address from being distributed by OSPF (Suggested for Multi-WAN environments" and clicking save). Making a change to any interface appears to reload the configuration in a way that all neighbors populate.

Actions #1

Updated by Jim Pingle almost 2 years ago

  • Project changed from pfSense to pfSense Packages
  • Category changed from Routing to WireGuard
  • Priority changed from High to Normal
  • Target version deleted (22.05)
  • Plus Target Version deleted (22.05)
  • Release Notes deleted (Default)
Actions #2

Updated by Johann Lohberger about 1 year ago

Hi,

just wanted to confirm. I can reproduce this issue on all of my installations so far. Mostly PFsense CE 2.6.0 with Wireguard 0.1.6_2 and FRR 1.1.1_7
I did not test this on my Netgate devices as they are in production and i prefer to test things in my lab before making changes to the production environment.

For me it is sufficient to klick "Force Service Restart" on the FRR global settings page. I do not need to make any changes to the settings.

Any combination to restart the services via the services tab or command line did not resolve the issue. Could this be some kind of race condition where the wireguard interfaces are not jet there while frr is starting its daemons?

Actions

Also available in: Atom PDF