Is this normal behavior for the Resolver to act that way?
-
@johnpoz Not according to pftop. I have rules that specify when going thru the VPN interface.
-
But is the client allowing the remote server to pass it a default route?
-
@stephenw10 I don't think so:
-
I usually just set don't pull routes. But it's easy enough to check what's happening there in the routing table.
You can't policy route traffic from the firewall itself so it will just use the system default route at that point. I'd bet that's what's happening.
-
@stephenw10 I will try.
Thank you. -
@marchand-guy yeah a peak at your routing table will tell you - you could also look here
the gateway you have set for your vpn should not be the default.
-
@johnpoz Looks good:
file:///home/guy/Downloads/Screenshot%20from%202025-05-30%2011-56-16.png -
@stephenw10 I tried the openvpn client seeting on not pulling route. It did not clear the problem. Furthermore, the gateway monitoring function for the vpn interface stopped working properly.
But your suggestion remains valid concerning the routing. Still investigating. -
@marchand-guy not sure what there is to "investigate" just look in your routing table. take all of 2 seconds
Unless you have a more specific route for your NS your pointing to - its going to go out the default route.
-
@johnpoz said in Is this normal behavior for the Resolver to act that way?:
@marchand-guy not sure what there is to "investigate"
Semantics...Looks fine to me but we don't have the same version, so:
file:///home/guy/Downloads/Screenshot%20from%202025-05-30%2012-54-37.png -
@marchand-guy well from that there its not routing traffic out any vpn..
I have 2.8 running now and could test.. But I can tell you with like 99.9% certainty I will not be able to duplicate it.. Because if 2.8 broke dns resolution with users that use vpn - the forums would be on fire with people complaining. So pretty sure whatever your issue is unique to your setup.
-
@johnpoz Agreed!
Thank you, again
-
It only happens after reboot though and restarting unbound after boot corrects it. So that suggests that the default route is wrong when Unbound initially opens the outbound state during boot only. For some reason!
-
@stephenw10 Exactly. Still investigating.
-
@stephenw10 So, I removed every packages, every openvpn clients (and associated interface, NAT and rules. Every rules and NAT forwarding related to DoT.
What remained for me was to put the NAT rules to automatic instead of manual. Since I upgraded to 2.8 CE from 2.7.2 the rules went from (forget the VPN1 interface, it was removed. this is an old picture):
To:
I then made sure to only select the DNS interfaces as follow:
Network interface LAN, Localhost
Outgoing network interface WAN, LocalhostAnd rebooted the FW.
This setting breaks the resolution sevice on the LAN side, as no internet sites are acessible via browser or apps.
Until I manually restart the unbound service. Then everything works.
At this point, I'm troying the towel and leaving the interfaces used for DNS at their defaul values; which is "All" for both settings. Everything works after that with a reboot.
F**k you OCD monkey!
-
Hmm, so it still failed at boot with outbound NAT set to automatic?
-
@stephenw10 said in Is this normal behavior for the Resolver to act that way?:
Hmm, so it still failed at boot with outbound NAT set to automatic?
I wonder if you have ever seen this in the system log after a boot or reboot
php-fpm 589 /rc.newwanipv6: Gateway, NONE AVAILABLE
I have every time and I only have one wan;gateway;ISP set DHCP. -
Yeah that's normal if you don't have a v6 gateway defined. It shouldn't cause a problem.
-
@stephenw10 System/routing/gateways default gateway set Automatic
and also tried WAN_DHCP both get no default route found and the no gateway. Also, have outbound mode set on Automatic outbound NAT rule too.
If I wait long enough (1-5mins) it just finds a route/gateway by itself usually. Until it does dns queries fail which is a problem. -
For IPv6 specifically?
