Bug #13153
closed
Static routes bound to WireGuard interfaces are not restored after down / up events
Added by → luckman212 over 2 years ago.
Updated over 2 years ago.
Affected Plus Version:
22.05
Description
This was tested on today's 22.05 snap: 22.05.b.20220512.0600 using WG package 0.1.6_1 / kmod-0.0.20211105_1 ¶
repro:¶
- set up a S2S WireGuard tunnel as per https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2s.html
- create static route to the far end subnet with the WGx interface selected
- everything works as expected
- go to VPN -> WireGuard -> click the "stop" button
- wait a few moments
- click the start button
- confirm tunnel is re-established ("green")
- route to remote LAN is lost, it has reverted to the default route
- go to System -> Routing -> Static routes -> click Save
- route is restored
Probably needs a similar fix to https://redmine.pfsense.org/issues/13099
I also played around with devd
, adding something like this to /usr/local/etc/devd/custom.conf
:
notify 100 {
match "system" "IFNET";
match "subsystem" "tun_wg[0-9]+";
match "type" "LINK_UP";
action "/usr/local/sbin/pfSctl -c 'interface linkup start '$subsystem";
};
...but in my testing, the command gets called too quickly, so the route fails to add. Running it manually about 10s later does "work" to restore the route though. So I don't know if the PR above covers
all cases where the tunnel flaps. I did test starting/stopping the service repeatedly, as well as downing the far-end of the S2S until the gateway was showing 100% packet loss and then bringing it back online. All worked ok for me.
Would love to know what you think about this Christian McDonald
- Project changed from pfSense Plus to pfSense Packages
- Category changed from Routing to WireGuard
- Status changed from New to Feedback
- Assignee set to Christian McDonald
- Target version set to Future
- Release Notes deleted (
Default)
- Status changed from Feedback to Resolved
Tested on 22.01 and on 22.05-BETA (built on Fri May 27 06:21:09 UTC 2022)
I wasn't able to reproduce this issue. Anytime I stopped WireGuard service and then started it again, all static routes occurred in route table and there was no issue at all with pinging remote hosts.
I marked this Bug as resolved.
Also available in: Atom
PDF