search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.6k stars 2.96k forks source link

Prevent routing LAN hosted DNS? #405

Closed privacyguy123 closed 1 year ago

privacyguy123 commented 1 year ago

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

ordex commented 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)

Pippin1st commented 1 year ago

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

privacyguy123 commented 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?

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.

ordex commented 1 year ago

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.

privacyguy123 commented 1 year ago

Misunderstood, you asked for log:

ordex commented 1 year ago

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

cron2 commented 1 year ago 
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 :-)

privacyguy123 commented 1 year ago 
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.

cron2 commented 1 year ago

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.

privacyguy123 commented 1 year ago

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?

cron2 commented 1 year ago

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

privacyguy123 commented 1 year ago

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?

cron2 commented 1 year ago

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).

privacyguy123 commented 1 year ago

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.

privacyguy123 commented 1 year ago

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?

cron2 commented 1 year ago

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).

cron2 commented 1 year ago

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?

cron2 commented 1 year ago

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...

privacyguy123 commented 1 year ago

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.

ordex commented 1 year ago

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.

privacyguy123 commented 1 year ago

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.

privacyguy123 commented 1 year ago

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.

cron2 commented 1 year ago

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)

privacyguy123 commented 1 year ago

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.

ordex commented 1 year ago

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..

cron2 commented 1 year ago

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.

privacyguy123 commented 1 year ago

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.

ordex commented 1 year ago

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?

privacyguy123 commented 1 year ago

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.)

ordex commented 1 year ago

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)

cron2 commented 1 year ago

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.

privacyguy123 commented 1 year ago

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?

privacyguy123 commented 1 year ago

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 ...

selvanair commented 1 year ago

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.

privacyguy123 commented 1 year ago

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.

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?