@stephenw10 Correct. Way longer than the tunnel rekey times, so something must prompt a configuration reload outside of that.
Or maybe the tunnel went down at some point and the config was reloaded when a reconnect was attempted.

@PiAxel said in update from 25.07 beta to 25.07 RC:

The last version doesn't work for me!

??

How do you know that the latest version doesn't work for you, before installing that latest version ?

( 😊 )

@Proton retro bowl said in VoWiFi slow failover when using GW Groups:

I have theese GW groups:
e947b6a3-6853-4534-a448-05e780e72965-image.png
I have a statis route for Mullvad GW to exit through starlink:
ebd2ec98-90a0-4646-9af4-8ddfd609bb32-image.png
On both Mullvad GW i have:
8f24a410-ce6b-430f-acb9-ce97a7ff84b0-image.png
The same for DOME GW.

Default Gateway is group :
adb3cbe1-1276-48a2-a07b-e29b797d6610-image.png

and the othe rgroup lookes like this:
5cfa03be-dd61-4bb0-b562-c4fc9dc6c5b9-image.png ,

I have also set:
ea0c1c09-dd93-4722-9479-dc0f019f06ea-image.png

And i have my floating rules like this:
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.

@gemg83 I see what you're saying - it could be the jump from 12.3 to 14 on the BSD side.

It really hampers the use of limiters in multi-WAN setups so it feels like an important bug (I call it a bug as it doesn't behave at all how the UI or documentation suggests, it's more like using them on a floating rule).

@JonathanLee said in DNSSEC Resolver Test site:

https://wander.science/projects/dns/dnssec-resolver-test/

The patato checker.

Uncheck :
77b420f9-5499-4301-8050-7c1f6a6560d3-image.png

and do the test again.

So that page, and this one : http://www.dnssec-or-not.com/ test if you've checked the resolver's DNSSEC capability, or not ^^

That web site is part of my collection of web sites that test several DNS(SEC) related things.
I 'admin' several web servers ( = domain names), I also use site use this one https://dnsviz.net/d/test-domaine.fr/dnssec/ to check out a domain name DNSSEC capabilities, as I need to be sure it works = me not messing up things when deploying it.
test-domaine.fr is a domain I rent and use to test things before I apply them on the domains that can't afford down time when I mess up (again).
Remember : if you set up DNSSEC wrong on your web server, mail server ( actually DNS domain name server ), your domain name will 'vanish' from the Internet.
DNSSEC was considered rocket science not so long ago and maybe it still is, as using it really implies that you know what DNS is.

The good thing about pfSense : when you install it, and don't change (add, remove) any pfSense DNS settings, it will use DNSSEC out of the box without the user (admin) even being aware of anything.
DNSSEC = that's why resolving (yourself, locally) is such a good thing.
Forwarding means : you have to trust some one else.

Last time I checked, half of Europe's web site are using DNSSEC, and the US was ... not really using it.
That changed a lot the last several years : DNSSEC is now somewhat mandatory for all government hosted sites world wide.

@jamesdun

@jamesdun said in DNS problem:

if the new machine wasn't picking up the correct DNS server

Well, launch

ipconfig /all

and it tells you what DNS server it uses.
Normally, a new Windows PC will use DHCP is so it's 'plug and play'.

@jamesdun said in DNS problem:

Both machines show the correct DNS server when NSLookup is launched, although the old one also gives it a name and the new one fails to do the reverse lookup

Looks like the new machine isn't allowed to do DNS requests against pfSense ?

@jamesdun said in DNS problem:

and the new one fails to do the reverse lookup

Humm. The new one's DNS request gets refused ...

@bimmerdriver You need one IP that can move between the routers. Technically both WANs can be private IPs…Comcast business allows for this even if their modem is bridged, then the shared IP is a public. Maybe that helps.

Wel, really strange
I disabled the Allo VPN floating rule and restarted pfsense
Now, VPN works even with the block rule and without pass rule, as expected
Really strange that it needed a reboot and the logs I posted above

@patient0 OK, that helped. I'm fairly certain I had tried clicking Add time before and it hadn't worked - with the error I previously reported. In any case, it worked for me now. Thank you!

@jc1976 can you check if you hit the same issue as: Squid: "Undefined symbol "_ZTVNSt3__117bad_function_callE" after upgrade to 2.8?

@stephenw10 I believe that is mpt attempting to talk to the RAID card as if it was in IT mode, trying to count the individual drives ("REPORT LUNS"), and the card replying "No, this is RAID, you can't talk to the drives directly" ("ILLEGAL REQUEST").

I'll run a fs check next time it's convenient to take down the entire network. Probably this evening.

@cmcdonald Appears to be back/fixed. Thanks.

You can set the size it rotates at and the number of files to retain in the log settings at Status > Logs > Settings. As long as you have the space you should be able to increase it.

@stephenw10 said in Gateway monitoring still not OK:

I would still expect to have seen dpinger try to ping and show loss rather than pending.

/etc/inc/gwlb.inc:

// dpinger returns '<gwname> 0 0 0' when queried directly after it starts. // while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen. // or does it, anyone? if so we must 'detect' the initialization period differently..

@AWeidner its just pfsense trying to proect you against a rebind. When you foward to something that is normal some external public NS - which normally should not be returning rfc1918.

You might want to read some of the history of rebind attacks. And why this good protection to have in place.

@NetworkNerd Just in case you haven't tried this yet. The new Netgate online installer does provide you the option to set up the WAN interface connection details such as PPPoE etc as part of the process. I'm not a fan of the choice to remove offline installers by any means but at least they do provide this functionality.

@gemg83 yes, that's the issue I'm having, thanks for letting me know! I haven't found any workaround yet, maybe we should place a bug report?