WG 0.1.5 / pfS+ 21.05.1 - 2 WAN→1 WAN failover, not "failing back"
-
@trumee Ok, I don't have any PPPoE systems to test with, so I'm guessing this is related to that.
Immediately after a fresh boot, what is the output of
wg showconf tun_wg0
(or whatever your wg tunnel interface is from theWG_IFNAME=
line in the script) -
@luckman212 said in WG 0.1.5 / pfS+ 21.05.1 - 2 WAN→1 WAN failover, not "failing back":
wg showconf tun_wg0
It is as follows,
#root: wg showconf tun_wg0 [Interface] ListenPort = 51820 PrivateKey = mykeyredacted [Peer] PublicKey = mykeyredacted AllowedIPs = 0.0.0.0/0 Endpoint = remotepublicip:51823 PersistentKeepalive = 25
-
@trumee That looks fine. I read some of the older comments and I saw that you had to use devd to trigger on the WANUP event for PPPoE. Is that custom config still in effect?
-
@luckman212 Yes, the devd trigger is still in place. I am on pfsense+ (22.05) now.
-
@trumee I'm guessing that this is a timing issue; maybe the PPPoE connection comes up too quickly and the lockfile from the previous run is still in place, etc. Can you try this modified version (removes the mutex check) and see if it behaves differently?
gist:
wgfix.sh
(no locks) -
@luckman212 Unfortunately, i am seeing a bigger issue right now for this WAN. I will back to this once that is resolved.
-
-
-
Wireguard aside, does failback work for just the WANs at Site A? Once I failover to my LTE, and WAN comes back up, my states on the LTE interface remain.
-
@ddbnj I created this to operate specifically on WireGuard states. If you need generic "fallback" state killing, you can try enabling the Reset all states if WAN IP Address changes option at the bottom of System → Advanced → Networking.
-
Thanks.
Evidently resetting all states works sporadically at best.
There is a long history of pfsense users asking for failback on interfaces. Scripts were written but no longer seem to be working.
https://forum.netgate.com/topic/135614/failback-from-primary-wan-after-failover-to-secondary-wan/19
I was hoping to repurpose your script.
-
@ddbnj Feel free to fork and modify it- I had a "StateKiller" package that I was working on to do more complex rule-based state killing / failback but I sadly never finished it. Not sure how much interest there is for that now that they added some more general purpose state killing options in the recent builds.