Hi,
I have a VMWare client running latest version of Manajro GNOME and I’m not able to ping any local device via hostname. Pinging by IP works and everything else but not matter what I try I’m not able to get hostname (netbios name) resolved. NetworkManager and dnsmasq is preinstalled. dnsmasq.service or systemd-resolved.service are not started. I’m not sure how NetworkManager works but I guess he does not use either of these but rather uses the /etc/resolv.conf to perform dns resolution. I’m not sooo familiar with network stuff so I’m lost at this point. Any ideas?
The VMWare network interface is defined as NAT, but I also tried with bridged.
/etc/NetworkManager folder is empty
/etc/resolv.conf:
Generated by NetworkManager
search localdomain
nameserver 192.168.80.2
/etc/nsswitch.conf:
passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd
publickey: files
hosts: mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
netgroup: files
You could try with avahi (systemctl enable --now avahi).
I’m currently testing it, but it seems this doesn’t help. I have followed this guide: Avahi - ArchWiki
That’s really frustrating.
I understand your issue as you ar running Manjaro inside a VMware virtual machine.
I think you are looking in the wrong place.
The client has no influence on conditions outside the VM - you will have to look at the host configuration for the VM in question - as only by configuring the host side correct you will be able to allow the VM to get a network address.
@linux-aarhus
I understand your issue as you ar running Manjaro inside a VMware virtual machine.
That’s correct. I have no problems with DNS, DHCP or anything else network related. I just can’t resolve hostnames. I have tried everything. I contrast I have a Windows 11 client and there I can ping the machine by its hostname:
ping SRV-File. SRV-File is a windows machine in a VPN network. It’s resolved as SRV-File.mydomain.local and its IP is 192.168.33.xy.
In Manjaro client I can also ping for 192.168.33.xy but I can’t ping for SRV-File, ergo it’s not a problem with the host.
The dead easy way is to add it to the hosts file
/etc/hosts
192.168.33.yy SRV-File
DNS is directly related to resolving hostnames.
Originally - the only way of resolvning hostnames was the hosts file - but as that task became tedious on large networks - several solutions was developed.
There is several resolvers available e.g. bind or dnsmasq.
You will need the avahi daemon service on your Manjaro system if you want to resolve .local - but if the network is NAT and the service you are trying to reach is outside the NAT’ted network you won’t find anything.
A network uses a broadcast address - that is the last address in the subnet - for a /24 network this is x.y.z.255 - when your Manjaro broadcast - who has name SRV-File this is broadcasted to x.y.z.255 - if the host exist on that subnet - it will respond with the address. If the device is on z.y.x.133 then it is outside the network known to your Manjaro - and you will never get any response.
That is what nameservers are for - they can be set manually or they can be assigned by the DHCP service - but they are all apps with a registry containing known hostnames and their corresponding ip address.
It can be fairly complicated to get all the bits and pieces to play together - especially for small consumer networks because it requires one to know how.
You can simplify it slightly by setting the VM nic to bridged mode.
Essentially bridged mode will let your VM get an address from the same DHCP service as the host.
If the nameserver provided by the DNCP service knows where SRV-File is then your Manjaro can find it.
If however - as you clearly stated - the server is on a VPN network - then this is provided by client running on your host - an your Manjaro will be none the wiser.
@linux-aarhus Thanks for your time. I’m aware of the part with the hosts file. But I wouldn’t know the ip address if I hadn’t my Windows 11 client to check for the ip address of SRV-File. So this is not a reliable or desired solution.
You will need the avahi daemon service on your Manjaro system if you want to resolve .local - but if the network is NAT and the service you are trying to reach is outside the NAT’ted network you won’t find anything.
This part is out of my range of experience to be honest.
A network uses a broadcast address - that is the last address in the subnet - for a /24 network this is x.y.z.255 - when your Manjaro broadcast - who has name SRV-File this is broadcasted to x.y.z.255 - if the host exist on that subnet - it will respond with the address. If the device is on z.y.x.133 then it is outside the network known to your Manjaro - and you will never get any response.
This is something I understand. I tried nmblookup -B 192.168.33.255 DC-File but I get always name_query failed to find name DC-FILE. I also tried other variations.
You can simplify it slightly by setting the VM nic to bridged mode.
Essentially bridged mode will let your VM get an address from the same DHCP service as the host.
Correct me if I’m wrong but in this specific case that doesn’t matter. I’m connecting via openvpn to my company network within VMWare Manjaro so the host DHCP is not aware of the company network. What I can say so far is that the Windows 11 client can handle it, no matter if NAT or Bridged and Manjaro not.
EDIT:
When starting openvpn I get the ip addresses of DHCP, DNS, WINS server of the new network: 192.168.33.xy. Maybe I have to add one of these addresses to some config files. I also tried this…added the DNS ip address into /etc/resolv.conf as nameserver but that didn’t help. But to be honest, I’m testing blindly. It’s just trial and error.
That simplifies your issue - I wouldn’t have guessed that you were using the client to connect to the corporate network.
For Manjaro to resolve hostnames on the remote network - the remote network must provide the resolver - this is usually done server side when assigning the IP address.
I have been sysadmin on Windows networks - and I now have a clear picture of what happens - talk to you employer’s IT - make them assign the corporate DNS to the VPN service - server side.
@linux-aarhus I can’t and don’t want to talk to them, it’s time waste. They don’t support linux. Bit I doubt I have to.
Don’t forget that my Windows 11 client resolves it out-of-the-box. Correct me if I’m wrong but when Windows client works and Linux client doesn’t it must be a problem with Linux and not the infrastructure…
Windows client connecting to a Windows network will always work suffice the credentials are good.
For years Windows networks used .local - even though it was designed for something completely different.
Windows has always used Embrace Enhance Exterminate.
You cannot assume a Windows dlient work - then Linux will work. Then you are going to be disappointed again and again.
Using Linux requires a lot more of the end user - and in an edge case like this - that is you.
If the server maintaining the endpoint doesn’t supply a resolver - then it is a configuration issue - it may be a design choice - to prevent VPN users from accessing internet while connected to the VPN.
When you want to use LInux to access your corporate network over VPN - and you don’t get a resolver - you will have to set it up manually.
You use nmcli to pull info on your connection - and you can use resolvctl to all a resolver to the list - suffice you know the address.
You can scan the network using arp-scan or ipscan
You can use NetworkManager to edit the connection properties - including nameserver used.
But there’s no turnkey solution - not that I know of.
@linux-aarhus ok is it somehow possible to prove that it’s exclusively a problem with the vpn network to resolve hostnames.
At least I can ping other VMWare clients by hostname, like the Windows 11 one, but other linux distributions too. I can also ping the host machine.
When you want to use LInux to access your corporate network over VPN.
It’s a bit confusing when you say that because I can access it. Via ip address I can access SRV-File and I could even mount it and browse files etc.
you will have to set it up manually
How would I do this? Meanwhile I have everything installed. nss-mdns, samba, smbfs, smbclient, dnsmasq, dhclient, dhcpcd. None of them are started. Currently only NetworManager is started, DNS is somehow working, I can access reddit etc.
EDIT:
resolvectl returns: Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
because it’s not started. Here is the output after starting systemd-resolvd.service:
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 192.168.178.1
DNS Servers: 192.168.178.1 192.168.80.2 192.168.33.xy 1.1.1.1
Fallback DNS Servers: 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google
Link 2 (ens33)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: 192.168.178.1 192.168.33.82 192.168.80.2
DNS Domain: fritz.box
Link 3 (tun0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
when you are connected to the vpn run mncli
nmcli
It will display some DNS configuration information among other things the server IP’s - if the DNS servers listed is not your corporate network then the following won’t work
Then use that information to query the server if an address is provided.
drill @192.168.33.2 SRV-File
see what you get
It seems there is what is commonly called dns leak - which mean the name server used is not the one provided by the VPN connection.
@linux-aarhus 192.168.33.2 is the Gateway. Here is the output:
nmcli ✔
ens33: connected to Wired connection 1
"Intel 82545EM"
ethernet (e1000), 00:0C:29:B0:63:89, hw, mtu 1500
ip4 default
inet4 192.168.178.19/27
route4 default via 192.168.178.1 metric 100
route4 192.168.178.0/27 metric 100
route4 109.xx.y.218/32 via 192.168.178.1 metric 0
tun0: connected (externally) to tun0
"tun0"
tun, sw, mtu 1500
inet4 10.xxx.y.7/24
route4 10.xxx.y.0/24 metric 0
route4 192.168.33.0/24 via 10.xxx.y.1 metric 0
route4 217.xx.yy.21/32 via 10.xxx.y.1 metric 0
inet6 fewhatever::fab7:abcdeea:6c85:9ac5/64
route6 fe80::/64 metric 256
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.178.1 192.168.33.82 192.168.80.2 # the last 2 are manually added in resolv.conf
domains: fritz.box
interface: ens33
Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.
Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details.
~ drill @192.168.33.2 SRV-File ✔
Error: error sending query: Could not send or receive, because of network error
Please let me know if I leak too much informations ^^. I’m not so deep into network stuff.
EDIT:
My resolv.conf:
nameserver 192.168.178.1
nameserver 192.168.80.2 # ip of Gateway of NAT network, I guess this does not make any sense here
nameserver 192.168.33.82 # ip of DNS server
nameserver 1.1.1.1
But systemd-resolvd.service is not started by default. I have started it now manually.
It appears you are getting dns resolvers from the network
drill @192.168.33.82 srv-file
You will have to implement the advise from Arch Wiki.
You need a couple of scripts to remove the default resolver and ensure only the resolver from the remote system is used.
@linux-aarhus Ok I have read the stuff and understand roughly what the purpose is but I’m not sure which one of the scripts I should use.
No dhcp service is running, no dns service is running, also systemd-networkd and systemd-resolved are not running by default. I mean I don’t know how the bits are currently working together. Only NetworkManager is running and it’s overwriting the resolv.conf somehow.
I can use resolvconf command from systemd-resolvconf, which is not installed or from openresolv, which is installed. The former one would require to have systemd-resolved.service started. Further:
Openresolv will not work out of the box because client.up will only create private DNS server entries. These require extra configuration of openresolv to work. See man 8 resolvconf for more details on private DNS servers in openresolv.
I’m lost here. Should I go with systemd-resolvconf or openresolv?
What does the “pull-resolv-conf” do? And then I would need one of the “update-resolv-conf” scripts.
Got it. Give me a second to recap.
The scripts - simply put - ensures that only the resolver defined in the remote network is used while the connection is up.
They restore the default when the connection goes down. To implement it
- copy the files to /etc/openvpn
- then edit your vpn connection config to
- allow script
- call the scripts on up and down (remember full path to script - as you copied /etc/openvpn/client.{up|down})
Manjaro defaults to use openresolv - so you wouldn’t have to do anything other than copying the files and modify your connection profile.
I have a personal preference for systemd-resolved and there’s scripts for that too.
@linux-aarhus ok I got to the point when starting openvpn it updates the /etc/resolv.conf. It works now.
I have reverted any change I did since I’m trying to resolve the hostnames of this vpn network. The only thing I have to do is:
sudo nano /etc/resolv.conf
search mycompany.local
nameserver 192.168.33.81
The ip of the DNS Server was already there but the missing search option was the solution! To ensure the file is not overwritten by NetworkManager I adjust the immutable flag:
sudo chattr +i /etc/resolv.conf
There is only one thing that I don’
t understand yet. When I put other nameserver before nameserver 192.168.33.81 the ping to SRV-File fails, e.g. when I write this:
search mycompany.local
nameserver 192.168.178.1
nameserver 192.168.33.81
pinging SRV-File fails. Any ideas?
This is how DNS works - the first server responding get the say-so.
It is because the system always ask the nameserver which is known to respond. Only when the service does not reponnd - the next ip is used and even the first server starts to respond - the system will continue use server 2 until it is not responding.
Which is why you need the script to remove your router DNS to ensure it is not asked.
Because when it is asked it will respond with nxdomain - which then stops the process.