Hi, sorry for reactivating an old topic. I would like to know if the status is still the same on this issue. It seems absurd to me that we would need to make things so much more complex to simply tell the firewall "if the gateway from the first VTI IPSec is down, use the second VTI IPSec". I am not sure if the implementation is too much of a hassle, but this feature would be greatly appreciated.

@DaHai8 It seems like an odd piece of hardware or at least how they've had it set up. Usually we set up a mesh as well and then roaming isn't a problem. We have I think one home user with an extender and IIRC that's the one where it sets up a different SSID then connects to the main SSID also, to relay the packets. But then one needs to switch between then. FWIW eero can be set up in "bridge mode" to function only as access points. It also can enable a guest network in bridge mode, if desired.

Its both fixed in 2.8.1 beta and 25.07-1 plus release (as expected)

Finally got the new fiber circuit installed. Everything works normally as expected now. It was some voodoo in the Comcast Coax Cable Modem that was blocking return traffic.

Traceroute from the outside world: vpsuser@test:~$ sudo traceroute -I a.b.c.164 traceroute to a.b.c.164 (a.b.c.164), 30 hops max, 60 byte packets 1 daniel.domesticagriculture.org.uk (103.144.176.193) 0.518 ms 0.470 ms 0.457 ms 2 wist.lyle.org (103.144.176.143) 0.479 ms * * 3 100.64.101.167 (100.64.101.167) 10.793 ms 10.781 ms * 4 * * * 5 * * * 6 * * * 7 * * * ... 100.64.101.167 is my router's WG client IP

@daltonch It is called policy based routing. https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

@ElGuapo Make a route using WAN2 to your endpoint-IP-address.

For the benefit of my future self… I’ve got the LTE interface to renew DHCP every 15 minutes. Not ideal, but should be enough to keep me online. Interface / DHCP client configuration / Advanced configuration / “Option modifiers” = “supersede dhcp-lease-time 1800” This requests the max lease time of 30 minutes, so renewal triggers in 1800/2 = 900s (15min)

@viragomann Thanks for the info! ill give that a go and see if I can get it working, knew it was probably something small I'm missing.

I've added an issue on redmine: https://redmine.pfsense.org/issues/16354

@greatbush while I have about 3 minutes here do you realize that windows machines by default will not allow pings and such from outside their own subnet to come in? Just trying to rule out any issues that you might have with Windows firewall on those machines..

@ThePowerPig So add an additional rule to allow access to internal subnets (best to create an RFC 1918 alias for this purpose), but at least for the IPs you want to access from the device in question, and move this rule up above of the policy routing rule.

@Nicholas97 Sticky connections are not enabled. Gateway status is fine. Weights for each LAN are set to 1 which should be fine for 2x gigabit connections and total bandwidth used of less than 1gbps. Will look at the logs but will have to figure out what I'm looking for ... will report back. I have read the multiwan load balancing docs pretty well and searched the forums here before posting this originally. Unless there are other pfsense forums you're referring to?

@Proton retro bowl said in VoWiFi slow failover when using GW Groups: I have theese GW groups: [image: 1751568295930-e947b6a3-6853-4534-a448-05e780e72965-image.png] I have a statis route for Mullvad GW to exit through starlink: [image: 1751568352001-ebd2ec98-90a0-4646-9af4-8ddfd609bb32-image.png] On both Mullvad GW i have: [image: 1751568423315-8f24a410-ce6b-430f-acb9-ce97a7ff84b0-image.png] The same for DOME GW. Default Gateway is group : [image: 1751568497527-adb3cbe1-1276-48a2-a07b-e29b797d6610-image.png] and the othe rgroup lookes like this: [image: 1751568531048-5cfa03be-dd61-4bb0-b562-c4fc9dc6c5b9-image.png] , I have also set: [image: 1751568573300-ea0c1c09-dd93-4722-9479-dc0f019f06ea-image.png] And i have my floating rules like this: [image: 1751568631542-a86219e7-b85f-4fb0-a8df-374beaeb0f04-image.png] Including QOS settings. The idea is that when the boat is near land the DOME GW is avtive and is top priority. VoWifi also exit there if possible. So - when we only have Starlink - i force all VoWiFi traffic through WG GWs to always have VoWiFi work even then starlink has exit node abroad (get norwegian ip = allowed ViWiFi). So to my question: When both Dome and starlink is online, i can call using VoWiFi, no issues. But when Dome failes, it takes several minutes (5-6) before the mobile again can call. or get a call. Why is this? I know we are using UDP trffic and STATES here and that a cell phone can have a delay before he checks and reestablishes VoWiFi again, but is there something i can do to make the transition to WG GWs through starlink faster? How can i kill the STATES faster? I have also tried sloppy states and state timeout set to 25, but with same result. Suggestions? THX! You can try implementing a script that automatically flushes states when it detects a Gateway change, as this will significantly reduce the switching delay. The problem you are experiencing is that VoWiFi UDP connections still hold the old state, so the device takes time to check and reset. When the state is refreshed immediately, VoWiFi will reconnect faster and avoid the current 5-6 minute wait. Additionally, you can also consider reducing the state timeout value further or enabling the flush states on gateway down feature if your system supports it.

To clarify what does work: What works is that from either site, a client device with an IP of 10.40.x.x is able to traverse the tailscale tunel to the other site by using the 10.65.x.x addresses. However, no device in this 10.40.x.x subnet can get to a 10.40.x.x IP at the other end. I realise that I am NATing the outbound connections rather than directly routing them due to the limitations of pfsense, so I am thinking I need to translate the 10.40.x.x subnet on the way out of the site, but nothing I have tried seems to work so far.