You are not logged in.

#1 2023-02-10 19:22:27

marrs
Member
Registered: 2022-12-29
Posts: 6

Unable to resolve domain names behind globalprotect VPN

My system is unable to resolve domain names that are behind a Global Protect
VPN. I can resolve them manually by linking the domains to their correct IPs
(provided by a colleague) in my /etc/hosts file.  Once there, I can access the
domains through the VPN.  This leads me to believe that the domain resolver is
at issue.

The VPN client is globalprotect-openconnect 1.4.9

The DNS resolver is systemd-resolved.  I'm also using systemd-resolvconf, which
is apparently necessary for extracting any changes that the VPN client makes to
the /etc/resolv.conf.

gpclient *does* make such changes, and from what I can tell, they are being
handled.  More on this later.

The issue that I have is that the DNS of the VPN is either not being found or
not being searched for.  I can confirm this by manually resolving the correct
IP to its domain in my /etc/hosts file.  I can also confirm it by using drill
to resolve the domain name of any of the sites behind the VPN.  They are
exposed to the internet so they do resolve to an IP, but it is different from
the IP returned by the VPN's DNS server.  I believe the servers are configured
to reject internet traffic at the application layer, so while I can resolve the
domain without a VPN, I can't complete an HTTP transfer unless I am both
connected to the VPN and using the IP exposed via the VPN.

I was able to troubleshoot this issue today with an Artix user, so he was using
many of the same tools as me and confirmed that we were being directed to
different IPs for the same domain name.  Obviously Artix ships without Systemd
so he was using some other resolver.  This leads me to think that
systemd-resolved may be the issue.

My friend's /etc/resolv.conf would be updated with settings that weren't
present in mine, but I think that is due to our using different resolvers.

I believe that I am getting those settings, because when I connect to the VPN,
I can confirm via `resolvectl status` that `tun0` is set up to use the DNS
server IPs provided by the VPN. These IPs are correct.  The DNS domain names
set up to resolve against those name servers are also correct.

The precise output of resolvectl (with private data redacted) is as follows:

```
Link 22 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: x.x.x.x
       DNS Servers: x.x.x.x x.x.x.y
        DNS Domain: xxxxxxxx.com
```

My own /etc/resolv.conf contains the following (with comments removed):

```
nameserver 127.0.0.53
options edns0 trust-ad
search xxxxxxxx.com
```

I have tried to manually match my /etc/resolv.conf to my friends but to no
avail.

Hopefully someone can help me troubleshoot this issue.  Thanks for any help.

Offline

#2 2023-02-10 20:58:09

-thc
Member
Registered: 2017-03-15
Posts: 485

Re: Unable to resolve domain names behind globalprotect VPN

If I understand you correctly, you are connecting to a network with a "Split-brain DNS" setup for the hosts you try to reach.

When you are connected to the VPN and use drill to resolve one of the critical host names - which DNS server is mentioned in the "SERVER:" field of the "ADDITIONAL SECTION:"?

If it's "127.0.0.53" - what's the output of "resolvectl query critical_host_name"?

If this shows the "outside" IP address ("Inside" meaning on-premise or VPN) systemd-resolved somehow chooses the wrong resolver.

You can either debug systemd-resolved (https://wiki.archlinux.org/title/System … _a_service) or switch to standalone openresolv/resolvconf (https://wiki.archlinux.org/title/Openresolv) for testing.

Last edited by -thc (2023-02-10 20:58:38)

Offline

#3 2023-02-12 23:11:53

marrs
Member
Registered: 2022-12-29
Posts: 6

Re: Unable to resolve domain names behind globalprotect VPN

Thanks for the advice.  Following your instructions, I can see that 127.0.0.53 is resolving the request and `resolvectl query` indicates that the external IP is being used, as suspected.

I tried to enable debugging by adding the following to `/etc/systemd/system/systemd-resolved.d/override.conf` but with no joy:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Nothing is put to journald when I try to curl, ping, or drill the domain in question.  The same applies for `systemd-networkd`.  At the default log-level, journald does report that Bus client sets DNS server and search to the expected values for tun0 when connecting to the VPN with gpclient.

Offline

#4 2023-02-13 07:25:31

-thc
Member
Registered: 2017-03-15
Posts: 485

Re: Unable to resolve domain names behind globalprotect VPN

Yeah - I pulled the "[Service]" hint from the Wiki and it doesn't work.

The only thing that seems to work for me: Stop resolved and start it in the foreground with the environment variable set:

systemctl stop systemd-resolved
SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved

You have to switch to another console (from Ctrl-Alt-F1 to Ctrl-Alt-F7) to issue drill or other commands.

Offline

#5 2023-02-16 19:16:26

marrs
Member
Registered: 2022-12-29
Posts: 6

Re: Unable to resolve domain names behind globalprotect VPN

Unfortunately the logs didn't help very much.  I'll post back if I'm able to find any more clues as to what's going on

Offline

#6 2023-02-16 19:23:48

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Unable to resolve domain names behind globalprotect VPN

systemd-resolved probably chooses your non-vpn DNS server when resolving the domain, the vpn-dns is only associated with the vpn link, you still have your normal network link that has a dns server as well. Only queries with a domain that is part of the "DNS Domain: " of the vpn will always use the vpn dns server.
https://systemd.io/RESOLVED-VPNS/
Something like this might work:

 resolvectl default-route eth0 true
 resolvectl domain tun0 '~.'
 resolvectl default-route tun0 true

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

Board footer

Powered by FluxBB