1

i have a device in my private network, let's call it "webserver". when i am directly connected to my private network at home then i can reach that server by using its host name, like http://webserver:1337. however if i connect to that network from a different network through VPN, like from work or from the library, my browser (firefox and chrome) can not resolve that hostname (both just using the system network configuration). if i run

dig webserver +short

i, don't get back an ip address. other hostnames however, like fritz.box (which is my router) do return the correct IP address.

dig fritz.box +short
192.168.178.1

so that makes me think that my VPN and DNS configurations are wrong and that i need to change them, because if i specifically ask my DNS server inside the VPN network, for that hostname, i actually get back the correct IP

> watch dig webserver @192.168.178.1 +short
192.168.178.46

in my VPN configuration the DNS server address is set to automatic so i assumed it would just retrieve the correct IP which looks like it should have worked, when i run

> systemd-resolve --status

[...]


Link 5 (tun0)
      Current Scopes: DNS

DefaultRoute setting: yes

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.178.1
         DNS Servers: 192.168.178.1
          DNS Domain: ~.


Link 3 (wlp3s0)
      Current Scopes: none
DefaultRoute setting: no

       LLMNR setting: yes 
MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

my local /etc/resolv.conf also doesn't show any special configurations:

nameserver 127.0.0.53
options edns0

an if i run ip r i can also see that the route to the subnet with the nameserver, looks like it's setup correctly:

default dev tun0 proto static scope link metric 50 
default via 192.168.0.1 dev wlp3s0 proto dhcp metric 600 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.236 metric 600 
192.168.0.1 dev wlp3s0 proto static scope link metric 600 
192.168.178.0/24 dev tun0 proto kernel scope link src 192.168.178.201 metric 50

This is my VPN config file from /etc/NetworkManager/system-connections/

[connection]
id=**redacted**
uuid=**redacted**
type=vpn
autoconnect=false
permissions=user:**redacted**:;
timestamp=1604833427

[vpn]
IKE DH Group=dh2
IPSec ID=redacted
IPSec gateway=redacted
IPSec secret-flags=1
Local Port=0
NAT Traversal Mode=natt
Perfect Forward Secrecy=server
Vendor=cisco
Xauth password-flags=1
Xauth username=redacted
ipsec-secret-type=save
xauth-password-type=save
service-type=org.freedesktop.NetworkManager.vpnc


[ipv4]
dns-search=
method=auto


[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto


[proxy]

ifconfig tun0 gives me:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1412
        inet 192.168.178.201  netmask 255.255.255.0  destination 192.168.178.201
        inet6 **redacted**  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 3334  bytes 3091010 (3.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2980  bytes 635324 (635.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

My systemd-resolved logs look mostly like this:

Dez 08 15:35:52 **redacted** systemd-resolved[1040]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Dez 08 15:35:52 **redacted** systemd-resolved[1040]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

one noteworthy thing here is that /etc/resolv.conf points to /run/systemd/resolve/stub-resolv.conf, which contains

nameserver 127.0.0.53
options edns0

some people suggest to just let it point to /run/systemd/resolve/resolv.conf, which contains:

nameserver 192.168.178.1

which IS the correct nameserver. but this would bypass resolved and can't be the solution to the problem.

i'd appreciate getting some pointers on how to further troubleshoot this issue. thanks in advance!

stephanlindauer
  • 71
  • 1
  • 8

1 Answers1

0

my local /etc/resolv.conf also doesn't show any special configurations:

nameserver 127.0.0.53

Did you try changing this to 192.168.178.1 (from what I gather that's your internal DNS server). Did you try to change your /etc/hosts just as a test and put in a line like:

192.168.178.1 webserver

(change IP and name to what they really should be)

LuxZg
  • 547
  • the change in /etc/hosts works as expected and if i put nameserver 192.168.178.1 into resolve.conf, it does start working in my browser, but that can't be the solution to my problem, because i don't want to always manually set this nameserver. i do expect to get that DNS server address from DHCP when i connect to the VPN and then my local systemd-resolve on 127.0.0.53 should forward to the DNS server on 192.168.178.1. – stephanlindauer Nov 18 '20 at 19:21
  • Ok, now at least we know that resolving actually works, and connections are fine, just need to see what's with DNS. Seems you need to share more details about VPN connection itself. Can you share config (redacted auth parts), or at least what you use to establish VPN and some general info. Can you post results of "ip a tun0" as well? – LuxZg Nov 18 '20 at 20:07
  • Could you also try to turn on debugging and see what journal says, as described here: https://unix.stackexchange.com/a/432077 – LuxZg Nov 18 '20 at 20:43
  • Few things to try. Remove that "options edns0" from resolv.conf, see if it helps, (there was a related bug), if yes, need it made permanent as reboot will restore it. If that's not helping, try adding custom file in "/etc/systemd/resolved.conf.d/*.conf" with setting for Fritz, though I don't expect much as resolve status already lists correct DNS. Service restart won't hurt but you probably did that first. Last option would be to disable systemd-resolved and switch to using resolvconf as alternative. But let's see if you find anything in journal first – LuxZg Nov 18 '20 at 21:26
  • sudo chattr +i /etc/resolv.conf – pierrely Nov 23 '20 at 05:38
  • thanks for your response @luxgz, i added the answers to your questions into the original question above. removing "options edns0" didn't help unfortunately. the other suggestions wouldn't really fix the underlying problem but would just bypass them, right? – stephanlindauer Dec 08 '20 at 15:12
  • There's two things that pop to my mind. First, when I read dns-search= line.. since you are writing example names, maybe we missed an important bit. What if you have some domain name, with a suffix, and your dns-search empty, would result in searching wrong name when outside local private network. Eg. if your full domain naim is webserver.mydomain.local either try accessing using full name, or add mydomain.local to your dns-search string. Second is partially answer to your question if my suggestions would just be workarounds. Answer is.. yes and no (depends :) ). See next comment – LuxZg Dec 08 '20 at 18:39
  • If you have any special cases we may have missed, using additional etc/systemd/resolved.conf.d/*.conf file is completely "legal". Eg., you can add FallbackDNS= or Domains= (equivalent to dns-search in VPN config). I'd certainly try adding 00-mydnsconf.conf to that folder with at least a fallback dns and domain name if you use it, and see if it helps. Both options will NOT hurt when you are connected to other networks, they will be used only when other (primary) dns options fail to resolve your webserver. There's third possibility, do you have split neworking or split dns on vpn? – LuxZg Dec 08 '20 at 18:45