25.07 RC - no default gateway being set if default route is set to a gateway group and the Tier 1 member interface is down
-
Mmm, a good solution here would be some anycast ping targets that aren't DNS servers. But using DNS servers there is really convenient!
-
Effectively, @luckman212โs request is for a static route that only applies to IGMP echos originating from the firewall itself.
-
@dennypage FWIW that doesn't happen currently even with pf. The route-to rule is based on the interface's source address with any destination that's not in the interface's subnet. Still, a rule can be created that applies to the correct traffic.
Given the feedback, it sounds like the issue isn't that a route should not exist, but rather some route is needed to allow pf to force the traffic. That's effectively the workaround @stephenw10 showed. Any potential undesired behavior from that kind of solution needs to be considered.
-
@stephenw10 said in 25.07 RC - no default gateway being set if default route is set to a gateway group and the Tier 1 member interface is down:
Mmm, a good solution here would be some anycast ping targets that aren't DNS servers. But using DNS servers there is really convenient!
Convenient yes, but from time to time, Google and others get annoyed with everyone using their DNS servers as monitor targets and put temporary blocks in place. I generally recommend people to use regional routers in their ISP instead.
-
@dennypage Exactly! I had written a script called
hopfinder
that I mentioned farther up, which already does this successfully & automatically for the FIOS connection, where traceroute works properly. On the LTE network, no such luck so I've resorted to querying the RDAP database (which had a nice parseable JSON output) for /32 hosts in T-mobile's network, and then iterating over a handful of them to find a few with the lowest latency. "it works" but the script takes about 45 seconds from start to finish, so not something to run every day, but once a week seems about right.I'm planning to publish the updated script soon, trying to decide if it's worth making into a full package with a GUI.
-
Would a workaround for the fees be to block from LAN to 8.8.8.8 with a policy routing rule? Or would the static route override that? (haven't looked, just brainstorming)
FWIW since it was mentioned above, pfBlocker can block DoT, which it has tucked under "DNSBL SafeSearch." Though as I've mentioned elsewhere I know that at least the Dish DVR video on demand "app" (though not the DVR software) is hardcoded to use Google DoT, I think it was.