Closed privacyguy123 closed 1 year ago
This route you highlighted is part of the mechanism that redirects all your traffic through the VPN connection. Why do you think this route is creating troubles?
Since 192.168.0.0/24 is your LAN, you most likely have a more specific route for it, which should always be selected when trying to reach the DNS.
From the command prompt can you ping 192.168.0.100? (with and without VPN enabled)
Hi,
You have to --pull-filter the DNS servers that Proton servers push to you,
pull-filter ignore "dhcp-option DNS"
Then add you own,
dhcp-option DNS 192.168.0.100
This route you highlighted is part of the mechanism that redirects all your traffic through the VPN connection. Why do you think this route is creating troubles?
When I manually remove it after starting OpenVPN (annoying workaround) my browser shows VPN ip + using local AdguardHome instance for DNS.
Hi,
You have to --pull-filter the DNS servers that Proton servers push to you,
pull-filter ignore "dhcp-option DNS"
Then add you own,
dhcp-option DNS 192.168.0.100
I added this but my AdguardHome instance isn't replying unless I remove that route I specified up there which is confusing to me. Is it perhaps a setting on the AdguardHome side that isn't responding to private IPs like the one I'm getting assigned? 10.x.x.x
From the command prompt can you ping 192.168.0.100? (with and without VPN enabled)
Replies both time and what's stranger is I can access the admin control panel with VPN on yet no DNS requests are reaching Adguard so I have no internet connectivity.
then it definitely sounds like you are being configured a different DNS when the VPN is enabled. so it is not really a routing problem (As expected), otherwise you'd not be able to ping it or to access the panel either.
How about you share the client log (possibly with verb 4) so we can check what's going on?
This said, this topic would be better discussed on the mailing list as this is not truly a bug report.
Misunderstood, you asked for log:
I see the DNS entry sent by the server is properly ignored. To be honest I am not a windows guy, so can't debug any further...maybe @lstipakov or @selvanair have some suggestion
2023-09-05 08:24:34 us=62000 Blocking outside dns using service succeeded
So there is a block-outside-dns
in the config, I'd say (it is not pushed, but active). Remove that one :-)
2023-09-05 08:24:34 us=62000 Blocking outside dns using service succeeded
So there is a
block-outside-dns
in the config, I'd say (it is not pushed, but active). Remove that one :-)
Setting removed. Still no connection. Log:
Honestly seems like a problem on the Adguard side, I can access it's admin panel at 192.168.0.100 but I can see in its logs that it's not doing any DNS requests when I try to surf which results in no internet, obviously.
If I run route DELETE 128.0.0.0 MASK 128.0.0.0 10.8.0.1 / route ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.1 (same thing I think?)
after VPN connection I see VPN IP and DNS requests coming from 192.168.0.11 (me) in the admin panel.
I've asked for help on their Github page.
Removing the route should not be necessary, as you have a more specific route for 192.168.0.0 255.255.255.0
in your routing table, and in routing "the most specific route wins". Also, you wouldn't be able to access the web UI if it's routing related...
I see that OpenVPN is still installing a DNS server on the wintun interface, and that one does not look reasonable
DNS SERV = 127.0.0.1/255.255.255.255
this seems to come from your config... remove everything with "DNS" from it, please, and retry.
Sorry that was done for testing purposes. Here is the config file.
windows-driver wintun
client
dev tun
proto tcp
pull-filter ignore "dhcp-option DNS"
# remote 154.47.24.193 8443
remote 154.47.24.193 443
# remote 154.47.24.193 7770
remote-random
resolv-retry infinite
nobind
# The following setting is only needed for old OpenVPN clients compatibility. New clients
# automatically negotiate the optimal cipher.
cipher AES-256-CBC
auth SHA512
verb 7
setenv CLIENT_CERT 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
reneg-sec 0
remote-cert-tls server
auth-user-pass
pull
fast-io
dhcp-option DNS 192.168.0.100
register-dns
For sanity I ran Chrome and it connects fine ... what on earth in FireFox would be preventing connection?
Hah, Firefox. Firefox does what it wants to, possibly even doing DNS over HTTP (DoH) to some random server somewhere on the Internet, "for privacy reasons" (I think this is a spectacularily idiotic thing to do, but browser vendors live in their own small world).
I found this, which might help https://techdocs.akamai.com/etp/docs/disable-doh-browsers
DoH is explicitly disabled in my FireFox - I can't think of a single other setting that could be F'ing with this ...
Why on earth would FireFox especially not work here?
If it's not DoH, I'm not sure what else firefox could be doing, sorry. But if chrome works, it hints at "DNS in general works now" (unless chrome does something else behind the scenes).
My preferred test for DNS is actually avoiding all the highlevel software, and running ping google.de
from a cmd.exe windows - ping will use the system resolver, not cache anything, and you can directly see what came back. nslookup
does something else again (query the system for "something DNS" and send its own queries, not using the system resolver).
If it's not DoH, I'm not sure what else firefox could be doing, sorry. But if chrome works, it hints at "DNS in general works now" (unless chrome does something else behind the scenes).
My preferred test for DNS is actually avoiding all the highlevel software, and running
ping google.de
from a cmd.exe windows - ping will use the system resolver, not cache anything, and you can directly see what came back.nslookup
does something else again (query the system for "something DNS" and send its own queries, not using the system resolver).
Google has it's internal DoH setting turned on internally I think ... now I have no connection with either browser.
Ping times out, nslookup works. I am at a loss.
As I say, everything works as I see it should with route DELETE 128.0.0.0 MASK 128.0.0.0 10.8.0.1
This route is totally broken, my AdguardHome hosted on the Pi doesn't seem know what 10.8.0.1 is therefore isn't replying to DNS requests from there. DNS can't go through a VPN tunnel and reach a LAN device surely?
No, the route is not broken. This is half the default route that you have asked for, to redirect "all Internet into the tunnel" (0.0.0.0/1 and 128.0.0.0/1).
Please read what I wrote: more specific routes are preferred before less specific routes. You do have a route for 192.168.0.0 255.255.255.0 pointing to the LAN interface, so packets matching that will never be affected by a 128.0.0.0/1 route.
Also, as I said before, if you can reach the management interface of that AdguardHome box, routing is correct, because routing does not care if it's ping, DNS or http.
Now it's well possible that "something in the Windows DNS machinery" gets refreshed when adding/deleting routes, so it seems as if deleting the route would fix it - but then you're missing half the VPN (like, my test box, v6.de, would no longer be routed through the VPN).
If you say "ping times out", does it do DNS resolution, and then time out? Or does it fail to do DNS? Can you copy-paste the output from ping v4only.v6.de
please?
Right now it more seems as if the VPN is just not working right, so "whatever goes through the VPN" is broken, and when you remove the route, "nothing more goes to the VPN", so it seems as if things work again... - the difference in ping "DNS fails" and "actual ping fails" will tell...
Right now it more seems as if the VPN is just not working right, so "whatever goes through the VPN" is broken, and when you remove the route, "nothing more goes to the VPN", so it seems as if things work again... - the difference in ping "DNS fails" and "actual ping fails" will tell...
❯ ping v4only.v6.de
Ping request could not find host v4only.v6.de. Please check the name and try again.
There is NO internet connectivity with that route set to tunnel through 10.8.0.1. It needs to go via LAN because the AdguardHome DNS server lives there. Either that or there's a setting over on that side that allows replying from private IPs - I can't see anything like that.
There is NO internet connectivity with that route set to tunnel through 10.8.0.1. It needs to go via LAN because the AdguardHome DNS server lives there.
10.8.0.1 is your VPN server. If sending traffic to the server is breaking your connection, then it means your VPN connection is not working at all.
There is NO internet connectivity with that route set to tunnel through 10.8.0.1. It needs to go via LAN because the AdguardHome DNS server lives there.
10.8.0.1 is your VPN server. If sending traffic to the server is breaking your connection, then it means your VPN connection is not working at all.
Not true, when I delete that route I see my VPN at Whoer.net and my DNS requests coming from 192.168.0.11 in Adguard admin panel. That route add is the problem, IMO.
Route table, OpenVPN, custom DNS, NO CONNECTION
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.11 35
0.0.0.0 128.0.0.0 10.18.0.1 10.18.0.7 4
10.18.0.0 255.255.0.0 On-link 10.18.0.7 260
10.18.0.7 255.255.255.255 On-link 10.18.0.7 260
10.18.255.255 255.255.255.255 On-link 10.18.0.7 260
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
128.0.0.0 128.0.0.0 10.18.0.1 10.18.0.7 4
154.47.24.193 255.255.255.255 192.168.0.1 192.168.0.11 35
192.168.0.0 255.255.255.0 On-link 192.168.0.11 291
192.168.0.11 255.255.255.255 On-link 192.168.0.11 291
192.168.0.255 255.255.255.255 On-link 192.168.0.11 291
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.0.11 291
224.0.0.0 240.0.0.0 On-link 10.18.0.7 260
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.0.11 291
255.255.255.255 255.255.255.255 On-link 10.18.0.7 260
===========================================================================
Route table, Wireguard, custom DNS, (128.0.0.0/1
in Allowed IPS
) CONNECTED
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.11 35
0.0.0.0 128.0.0.0 On-link 10.2.0.2 5
10.2.0.2 255.255.255.255 On-link 10.2.0.2 261
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 10.2.0.2 261
128.0.0.0 128.0.0.0 On-link 10.2.0.2 5
192.168.0.0 255.255.255.0 On-link 192.168.0.11 291
192.168.0.11 255.255.255.255 On-link 192.168.0.11 291
192.168.0.255 255.255.255.255 On-link 192.168.0.11 291
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.0.11 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.0.11 291
===========================================================================
THIS is the route thats fucked 128.0.0.0 128.0.0.0 10.18.0.1
On-link
is where it should be poined to allow local hosted DNS.
You have the same 128.0.0.0/128.0.0.0 route in wireguard, and you claim it's working. So would you please stop ignoring basic facts of networking? ("on link" needs to be taken with the correct interface ID, and it's pointedly not pointing towards your LAN but to the wireguard tunnel)
You have the same 128.0.0.0/128.0.0.0 route in wireguard, and you claim it's working. So would you please stop ignoring basic facts of networking?
How are
128.0.0.0 128.0.0.0 10.18.0.1 10.18.0.7 4
128.0.0.0 128.0.0.0 On-link 10.2.0.2 5
"the same"?
You're ignoring what I'm telling you about what I'm literally SEEING live on my machine. Removing that route does not break VPN connection, whatsoever. It fixes the custom local DNS though.
Removing that route stops sending traffic falling into the 128.0.0.0/1 subnet to the VPN. That traffic will go through your upstream connection. The other half (0.0.0.0/1) will still go through the VPN.
Now, you said that you can ping 192.168.0.100 when the VPN is enabled, right? If you can do that, then it means that routing is working and the issue must be on another layer..
First if all, network and netmask are what "catches" a packet. So you have both 128.0.0.0
and 128.0.0.0
here. Then comes "gateway" and "interface". In the OpenVPN case, the gateway is the VPN server, while in the Wireguard case, the gateway is on-link
but on the 10.2.0.2 interface, which is the Wireguard tunnel. Neither is your LAN interface, which would have 192.168.0.11
in the 4th column.
I am happy to believe that something is not working, but your insistence on this route being the culprit is not helping going forward with finding out what the actual problem is.
Removing that route stops sending traffic falling into the 128.0.0.0/1 subnet to the VPN. That traffic will go through your upstream connection. The other half (0.0.0.0/1) will still go through the VPN.
Now, you said that you can ping 192.168.0.100 when the VPN is enabled, right? If you can do that, then it means that routing is working and the issue must be on another layer..
We are in agreement there is an issue in some layer - how does that explain me manually editing that route fixing everything?
"Half" through VPN is what I am trying to achieve is it not lol? Internet traffic thru VPN, DNS traffic routed locally to AdguardHome hosted on a Pi. With this route set by OVPN its broken, when set by WG it's fine - makes 0 sense to me.
We are in agreement there is an issue in some layer - how does that explain me manually editing that route fixing everything?
This is what we are trying to understand..there might be various reasons why that helps..
"Half" through VPN is what I am trying to achieve is it not lol? Internet traffic thru VPN, DNS traffic routed locally to AdguardHome hosted on a Pi. With this route set by OVPN its broken, when set by WG it's fine - makes 0 sense to me.
No, this is not "half". This is "all traffic except DNS". The 127.0.0.0/1 and the 0.0.0.0/1 subnets are really splitting the whole Internet in two halves. It's a trick used to avoid conflicts with the default route (0.0.0.0/0). So if you remove one of the two, you are literally not routing half of the Internet through the VPN anymore (this is why also wireguard requires that route)
Anyway, can we go step by step? I asked to confirm if pinging 192.168.0.100 when OpenVPN is connected (without touching the routes) works or not. Do you have an answer?
Anyway, can we go step by step? I asked to confirm if pinging 192.168.0.100 when OpenVPN is connected (without touching the routes) works or not. Do you have an answer?
Sorry, thought that was one of the first things we confirmed. I can ping my Pi (192.168.0.100) and access it's AdguardHome admin panel @ 192.168.0.100:8083 while connected to OpenVPN with the custom DNS. No internet in either browser with DoH now forced off in BOTH. (Previously was on in Chrome.)
Anyway, can we go step by step? I asked to confirm if pinging 192.168.0.100 when OpenVPN is connected (without touching the routes) works or not. Do you have an answer?
Sorry, thought that was one of the first things we confirmed. I can ping my Pi (192.168.0.100) and access it's AdguardHome admin panel @ 192.168.0.100:8083 while connected to OpenVPN with the custom DNS. No internet in either browser with DoH now forced off in BOTH. (Previously was on in Chrome.)
Ok. Do you also agree that if we can ping 192.168.0.100, then "routing" must be working?
Now, removing the route triggers "something" which makes DNS work again..not sure what yet.
If you first remove the route and then add it again, does DNS continue to work? (please check the routing table to make sure it was re-added properly)
Sorry, thought that was one of the first things we confirmed. I can ping my Pi (192.168.0.100) and access it's AdguardHome admin panel @ 192.168.0.100:8083 while connected to OpenVPN with the custom DNS.
And here we are again. If that works, routing is fine. Routing does not care if it's DNS or http or ping packets (unless you mess with policy tables, which we do not do). Also you say "nslookup" is working, which hints at "if DNS queries are sent, they reach the server".
So the question is "where does windows send its packet, and why". Please remove the "dhcp-option DNS" from your config, it might actually prod windows into "send packets into the tunnel" when it shouldn't.
Anyway, can we go step by step? I asked to confirm if pinging 192.168.0.100 when OpenVPN is connected (without touching the routes) works or not. Do you have an answer?
Sorry, thought that was one of the first things we confirmed. I can ping my Pi (192.168.0.100) and access it's AdguardHome admin panel @ 192.168.0.100:8083 while connected to OpenVPN with the custom DNS. No internet in either browser with DoH now forced off in BOTH. (Previously was on in Chrome.)
Ok. Do you also agree that if we can ping 192.168.0.100, then "routing" must be working?
Now, removing the route triggers "something" which makes DNS work again..not sure what yet.
If you first remove the route and then add it again, does DNS continue to work? (please check the routing table to make sure it was re-added properly)
route del - fixes, as mentioned above route (re)add - back to broken
remove dhcp-option DNS
Oof ... leaving DNS blank does connect to Adguard. Wtf?
Messing with this a little more ... it seems WireGuard wants 128.0.0.0/2
or higher to allow the connection to AdguardDNS to happen - does this help either of you understand any further? It makes no sense to me ofc lol.
EDIT: or leaving DNS blank again "fixes" it. It doesn't feel like that should be a "fix" though ...
If you want use a DNS server outside the VPN, you should not be setting DNS server in the VPN config file at all. What it does is to set an "interface-specific" DNS server which should be reachable via that interface. Which is not your case.
Instead, set DNS server 192.168.0.100 on your default LAN interface before starting the VPN -- this should have been set by your LAN router via DHCP, but if not using DHCP, you can set this manually on the LAN interface. Then leave out any dhcp-option DNS ...
in the config file. Also use pull-filter ignore
to remove the pushed DNS server as well as any block-outside-dns option. And try again.
Do not mess with the 128.0.0.0/1 route as others have repeatedly pointed out. There is no issue with the outing table you have posted. You do not understand routing does not mean its broken. Also, please understand that this way DNS traffic will flow unencrypted, bypassing the VPN. It appears that is what you want.
If you want use a DNS server outside the VPN, you should not be setting DNS server in the VPN config file at all. What it does is to set an "interface-specific" DNS server which should be reachable via that interface. Which is not your case.
Instead, set DNS server 192.168.0.100 on your default LAN interface before starting the VPN -- this should have been set by your LAN router via DHCP, but if not using DHCP, you can set this manually on the LAN interface. Then leave out any
dhcp-option DNS ...
in the config file. Also usepull-filter ignore
to remove the pushed DNS server as well as any block-outside-dns option. And try again.
Already set, makes sense why it works I guess. :)
Do not mess with the 128.0.0.0/1 route as others have repeatedly pointed out. There is no issue with the outing table you have posted. You do not understand routing does not mean its broken. Also, please understand that this way DNS traffic will flow unencrypted, bypassing the VPN. It appears that is what you want.
Thanks for making this make sense! Adguard traffic is still encrypted via DoH though ... just not through the VPN set by OVPN/WG?, right?
Describe the bug Can't get any internet connection out when forcing OpenVPN to use AdguardHome on Pi as DNS (192.168.0.100)
To Reproduce Connect to OpenVPN with supplied ProtonVPN config file.
Expected behavior I expect to be able to connect to the internet.
Version information (please complete the following information):
Additional context Pretty sure it's this rule/route that's being added automatically that's killing it. I can't find a way to reject/ignore this one single route without breaking the whole VPN connection.
route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.1