Enable "block-outside-dns" on two parallel tunnels results in no DNS

[supergregg]

Hi.
I tried enabling the "block-outside-dns" on two tunnels that i normally have running in parallel and i get no DNS resolves at all. Disabling it for one tunnel enabled DNS again but only for that tunnel, as expected.

I was expecting this to work so that both tunnels DNS servers would work, or at least one of them and that no leaks would appear on the native interface.

[ValdikSS]

Is there a valid reason behind this? Are you trying to achieve sort of split tunneling and you need 2 DNS servers?
This is a known, yet not documented issue. I couldn't think of any setup that would require block-outside-dns in multiple tunnels and didn't bother to implement this.
If you have a valid reason, you're probably right and this should be fixed.

[supergregg]

Well, at work, we use a Internet only connection where i sit. So to access company resources i need VPN. That VPN is normally set to Tunnel All. But i also need to access my home VPN for special files and backups etc and switching between them constantly is a pain. As the Internet only connection uses Google DNS i don't want to leak our internal hosts to the outside. To my personal DNS at home is OK but i would prefer not to send it off to Google. So what i would like to limit is that DNS queries only enter the VPN tunnels and nothing else. I could fix this by simply only enabling on one tunnel but that results in no DNS for the other tunnel, so i would have to choose to have DNS for home or for company. Maybe thee is a better way that i'm not currently aware of...

[Selva Nair]

Here is a link to a proposed patch to support block-outside-dns on multiple tunnels:
​https://github.com/selvanair/openvpn/tree/block-dns-sublayer-2.3 (for release branch)
​https://github.com/selvanair/openvpn/tree/block-dns-sublayer (for master branch)

Would be great if you can test it.

[supergregg]

I would gladly test it, alas, I'm not a programmer and have no idea on how to compile that source for windows.

[Gert Döring]

@samuli: can you build a 2.4 installer with selva's block-outside-dns v2 included? It's on the list as well

Message-Id: <1474085439-28766-1-git-send-email-selva.nair@…>
​http://www.mail-archive.com/search?l=mid&amp;q=1474085439-28766-1-git-send-email-selva.nair@gmail.com

I'll do the review, but a test by someone who actually ran into the issue would be very welcome.

[Samuli Seppänen]

@cron2: installer with Selva's patch ​here.

[supergregg]

Well, that version is totaly not working for me. I can't access anything through the tunnel at all so no way to test Selva's patch. Im running Win10.

[Selva Nair]

@supergregg: The test installer is for version 2.4 while you were running 2.3.11 earlier, right? Installing 2.4 on top of 2.3 should work, but just wondering could something in your config file not sitting well with 2.4.. Are you now running the GUI as limited user (with interactive service running) or as admin as was required for 2.3.11?

Do the client logs or GUI status messages show any errors? A look at logs with verb = 4 may help.

(edit: typo fix)

[supergregg]

I tested to set logging to 4 and found that "Bad compression stub decompression header byte: 102" was logging.
So i set "comp-lzo yes" instead of "comp-lzo no" and now it all works. Selvanair's patch works and i can no longer see any leaking DNS traffic from my computer while running two VPNs in parallell.

So apparently something related to LZO compression has changed in 2.4 that was not there in 2.3. Someone might have to look into it as a mismatch in config here results in no traffic in the tunnel. But it might be working as intended, yet, a better error message might be good if the compression settings are enforced differently now.

[supergregg]

Just want to say thank you for this, it's a very welcomed feature! And thanks for all the help and support. You guys are doing a great job!

[Selva Nair]

@supergregg: Thanks for testing.

As for high-dpi displays, we do need some improvements. Will look into it.

Compression related options have undergone some changes but should be compatible with 2.3. @cron2: any idea what could cause this need to change --comp-lzo in client config?

[Gert Döring]

Selva's patches have been merged today, so the upcoming 2.3.14 and 2.4.0 release will have them. Thanks for testing and reporting back.

commit fc30dc5f20d455242ed8489fb1a99446287ba9cb (master)
commit f65f85275aeee79ebfdee5e1e00008b6f6508106 (release/2.3)
Author: Selva Nair
Date: Sat Sep 17 00:10:38 2016 -0400

Support --block-outside-dns on multiple tunnels

As for the comp-lzo breakage - I need to go test. "--comp-lzo no" has always been a bit of a weird edge case - I think it is interpreted as "do not compress but understand incoming frames with lzo compression", and it's distinctly different from "no --comp-lzo in the config" (which would mean "do not understand anything about lzo").

The whole compression thing got overhauled for 2.4 to support different compression algorithms (also server pushable now), so this might be not glitch-compatible. Sorry for that.

[Selva Nair]

@supergregg: I have made some changes to the GUI to support high-dpi displays. Could you please test the GUI executable ​here (64bit). To test, no installation is required -- just copy the test GUI executable to the Desktop of a system where openvpn-2.4 is installed and start it as a limited user.

[supergregg]

@selvanair
It works and looks good.

I'm nitpicking here but I noticed the icon in the task bar became a bit fuzzy with the High-DPI aware exe.
I have attached a PNG. The top icon is from the high-DPI exe and the bottom one is the original 2.4 icon.
Also, if the icon is ment to be in line with Windows 10 design, It probably doesn't need a black outer border?
But I'm really nitpicking here, sorry!

[supergregg]

Icon with High-DPI and without.

[Selva Nair]

Discussion on high-dpi moved to ​Ticket 772

[Antonio Quartulli]

@selvanair I think this ticket can be closed now that the DNS patch has been merged?