WG 0.1.5 / pfS+ 21.05.1 - 2 WAN→1 WAN failover, not "failing back"

luckman212

@trumee Haven't explicitly tested it with 22.05, but I have it running successfully on 22.01 with the most recent WG package. I plan to update a couple of them to 22.05 this weekend so I can definitely post back with results. In the meantime, what's in your logs? The script logs a bit of detail, if you filter on wgfix.

trumee

@luckman212 I am still on pfsense 2.6.0. Thanks for reminding me about wgfix. I did a cold boot and issued /root/wgfix.sh WAN3_PPPOE 0 and WG used the WAN i wanted.

Here is a what the log shows,

#cat /var/log/system.log | grep wgfix
Jul  2 02:00:55 pfSense wgfix[4608]: /root/wgfix.sh called, args: WAN3_PPPOE 0
Jul  2 02:00:55 pfSense wgfix[4994]: acquiring lockfile
Jul  2 02:00:55 pfSense wgfix[5279]: WAN UP: WAN3_PPPOE
Jul  2 02:00:55 pfSense wgfix[5819]: WG endpoint could not be determined
Jul  2 02:00:55 pfSense wgfix[6140]: done, removing lockfile
Jul  2 02:22:20 pfSense wgfix[44381]: /root/wgfix.sh called, args: WAN3_PPPOE 0
Jul  2 02:22:20 pfSense wgfix[44775]: acquiring lockfile
Jul  2 02:22:20 pfSense wgfix[44813]: WAN UP: WAN3_PPPOE
Jul  2 02:22:20 pfSense wgfix[44974]: WG endpoint: redacted:51823
Jul  2 02:22:20 pfSense wgfix[44980]: pausing 20s to allow gateway change to occur
Jul  2 02:22:40 pfSense wgfix[47710]: Default gateway iface: pppoe2
Jul  2 02:22:40 pfSense wgfix[48920]: found        1 bad states; bouncing wg service
Jul  2 02:22:47 pfSense wgfix[75223]: killing state 615abf6200000002/801cbc2f
Jul  2 02:22:57 pfSense wgfix[69630]: done, removing lockfile

Notice after a cold reboot the message is WG endpoint could not be determined, however once i issue the command manually the WAN is changed to WAN3_PPPOE.

luckman212

@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 the WG_IFNAME= line in the script)

trumee

@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

luckman212

@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?

trumee

@luckman212 Yes, the devd trigger is still in place. I am on pfsense+ (22.05) now.

luckman212

@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)

trumee

@luckman212 Unfortunately, i am seeing a bigger issue right now for this WAN. I will back to this once that is resolved.

luckman212

2.0: https://github.com/luckman212/wgfix

ddbnj

@luckman212

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.

luckman212

@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.

ddbnj

@luckman212

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.

luckman212

@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.