1

There's a nameserver 10.92.131.26 on my work VPN, and it appears to get configured on my machine when I connect to our anyconnect VPN server. When I run nslookup server on my Linux workstation, I get a SERVFAIL for it:

;; Got SERVFAIL reply from 10.92.131.26, trying next server
Server:     10.50.177.208
Address:    10.50.177.208#53

** server can't find server: SERVFAIL

But when I open a Windows VM within my workstation run and run nslookup, it succeeds for the very same nameserver.

Default Server:  a.company.domain
Address: 10.92.131.26

Why is this?


TMI: Why do I care? At work, our MFA system applies extra restrictions when I attempt to access certain of the company websites using my Linux workstation, but I don't experience these restrictions when I boot to Windows, nor when I attempt from a Windows VM from within my Linux system. (And I can't satisfy these extra restrictions because I.T. appears not to have planned on anyone actually encountering them legitimately.)

I.T. tells me:

Normally this is due to an issue with the VPN routing to [our] servers... Try it in Google Chrome if it still doesn't work as Firefox sometimes uses its own DNS to resolve addresses so it can cause this error where Chrome will just work.

...And indeed, their assertion seems well founded: in the Windows VM, my connection attempts through Chrome succeed, and my attempts through FF do not. Still, my attempts on my Linux host do not work at all.

I wonder if my attempts from Linux will succeed if I can get my Linux machine to use 10.92.131.26 for its nameserver.


Outputs

Update: as requested, here are the outputs to netstat -rn on each machine. They're pretty long, so I'm just linking pastebins: on Linux, on Windows

Here's a tracert 10.92.131.26 from the Windows VM:

Tracing route to 10.92.131.26 over a maximum of 30 hops

  1    29 ms    27 ms    25 ms  192.168.100.1 
  2    35 ms    31 ms    33 ms  173.36.212.117 
  3    35 ms    34 ms    29 ms  50.216.158.108 
  4    41 ms    35 ms    37 ms  10.92.131.26 

Trace complete.
4
  • The host cannot find the server, but the VM (assuming NAT or BRIDGED adapter) on the host can. That means that there is a network-path to the nameserver, Add the output of netstat -rn on both Linux and Windows to the question, please. Commented Jan 28, 2022 at 17:16
  • Righto, @LjmDullaart . I've added pastebin links to the output of netstat -rn on each OS.
    – Jellicle
    Commented Jan 28, 2022 at 17:27
  • Argh. You need some serious redesign of the network, if this is the routing table on a work-station. Try route add -net 10.92.131.0 netmask 255.255.255.0 gw 10.0.2.2 on Linux. Note that this is NOT the solution, only a step in the debugging. Commented Jan 28, 2022 at 17:41
  • Thanks, @LjmDullaart . In response to sudo route add -net 10.92.131.0 netmask 255.255.255.0 gw 10.0.2.2, I get only SIOCADDRT: Network is unreachable.
    – Jellicle
    Commented Jan 28, 2022 at 17:43

1 Answer 1

0

As it gets now a bit more elaborate than can be expressed in comments, I will (ab)use an answer.

What we see is two machines:

  • A Linux machine, with an IP probably in the 192.168.68.0/24 and a gateway of 192.168.68.1
  • A VM with Windows, with an IP in 10.0.2.0/24 and a gateway 10.0.2.2.

The 10.0.2.0/24 network is what the VM sees. Now, we're missing a bit of information. I am assuming from the information above, that the Windows VM has a bridged adapter, and that the VPN is set-up from the Linux host. Please verify this.

If the Linux host provides the VPN, it should be able to reach the gateway of the VPN. With ifconfig, you should be able to see the IP address on the tun interface. You must be able to reach the gateway on the VPN tunnel, otherwise you will not be able to route anything through the tunnel.

Your windows VM sees 10.0.2.2 as the gateway on the VPN; therefore, your Linux host should be able to see that as router too. It is therefore strange that you did get a network unreachable when adding the specific route to your Linux box; are you sure that the VPN was up when you tried to add the route?

As an additional debug information, a tracert from the windows client to 10.92.131.26 would be helpfull.

1
  • Thanks, Ljm! (1) The Windows VM is using NAT. (2) In order to satisfy the MFA, the VPN connection apparently must take place within the VM. (3) On the Linux host, ifconfig does show the Linux host's IP address on the tun0 interface; and indeed, I must be accessing it successfully because I can reach various servers on the VPN. (4) I am confident that the VPN was up when I tried to add the route; I was ssh'ed to one of our servers at the time; I have repeated the experiment with the same results. (5) I have added the tracert from the Windows VM to the OP.
    – Jellicle
    Commented Jan 31, 2022 at 16:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .