(solved) 2.5 connecting via hostname not working across interfaces
-
Not sure if this is the right place.
I used to connect RDP via hostname, this has always worked for me with 2.4.5.
Now with a fresh 2.5 it works only on the same interface.
I could add the domain under general setup and that works, but I am curious why it is not working with hostname only between different interfaces anymore. -
broadcasting for a name isn't going to work across networks. Did you have some other avhai or pimd working for discovery?
Did you change the domain - so your clients are no longer adding suffix to a search when you use just a host name.
dns always has to be fully qualified to resolve..
-
@johnpoz No, just installed pfsense from the get go. Don't know why it worked before.
-
What was your old version of pfsense? Long time ago dns would resolve just hostnames - but that bug was removed back 2.x something.. Multiple versions back..
If you want to resolve by just putting in hostname, set your device to use search suffix for the domain your using..
example..
$ ping nas Pinging nas.local.lan [192.168.9.10] with 32 bytes of data: Reply from 192.168.9.10: bytes=32 time<1ms TTL=64See how it comes back fully qualified while just using nas.. Because the OS is auto adding local.lan when it does the dns query..
-
@johnpoz Always used the most recent version and my client is Windows without a domain. And I changed the domain in 2.4.5p1 to home.arpa already and that hostname only thing still has worked for my. So the only thing changed was a fresh install of pfSense version 2.5!
If I remember correct you had to do a reboot on pfSense to get this working, after adding the static mappings in the DHCP server. -
cat /etc/hosts
Is the devices to which you RDP-connect listed ?
I can (pfSense 2.5.0) use host names :
No need to use the hostname.network.tld format, although that works to.
Btw : the device I RDP to have static DJCP MAC leases.
-
@gertjan Hey gertjan, they are listed with IP, domain name and hostname only and it is still not possible for me to connect via hostname only, if the target is on another interface/subnet. And that has worked before. Maybe it shouldn't work, then I am ok with it, I am open to change, but found it noteworthy.
-
The /etc/hosts file is used to populate the local unbound resolve cache.
So, unbound knows about them.Check for yourself, on the console :
dig @127.0.0.1 deviceIt should give you the correct answer.
Now, dig (or nslookup) on the device from where you RDP from. Is DNS working ? If yes, it should resolve the hostname you are using to connect to.
-
@gertjan It is not working like that in a fresh pfSense 2.5 I guess:
[2.5.0-RELEASE][admin@pfSense.home.arpa]/root: dig @127.0.0.1 mail ; <<>> DiG 9.16.11 <<>> @127.0.0.1 mail ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57206 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mail. IN A ;; AUTHORITY SECTION: . 3600 IN SOA a.root-servers.net.nstld.verisign-grs.com. 2021030100 1800 900 604800 86400 ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Mar 01 09:33:29 CET 2021 ;; MSG SIZE rcvd: 108 [2.5.0-RELEASE][admin@pfSense.home.arpa]/root: dig @127.0.0.1 mail.home.arpa ; <<>> DiG 9.16.11 <<>> @127.0.0.1 mail.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29863 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mail.home.arpa. IN A ;; ANSWER SECTION: mail.home.arpa. 3600 IN A 192.168.92.10 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Mar 01 09:36:17 CET 2021 ;; MSG SIZE rcvd: 59 [2.5.0-RELEASE][admin@pfSense.home.arpa]/root: -
@bob-dig
See the image of mu RDP connect above, it lists my LAn device I 'RDP' to .The full (local) domain name was needed :
[2.5.0-RELEASE][admin@pfsense.me.net]/boot/kernel: dig Bureau2 +short [2.5.0-RELEASE][admin@pfsense.me.net]/boot/kernel: dig Bureau2.me.net +short 192.168.1.2From a windows device,it worked with the host name only :
C:\Users\Gauche>nslookup Bureau2 Serveur : pfsense.me.net Address: 2001:470:1f13:5c0:2::1 Nom : Bureau2.me.net Addresses: 2001:470:1f13:5c0:2::88 192.168.1.2Probably because my Windows prefixes (appended ?) the local domain name.
-
@gertjan It is not working here and my windows is not new. Host file is empty on it, just checked. And it had worked on the last days of the old pfSense, where I already changed the domain to home.arpa...
PS C:\WINDOWS\system32> nslookup mail Server: pfSense.home.arpa Address: 192.168.1.1 *** pfSense.home.arpa can't find mail: Non-existent domain PS C:\WINDOWS\system32> nslookup mail.home.arpa Server: pfSense.home.arpa Address: 192.168.1.1 Name: mail.home.arpa Address: 192.168.92.10 PS C:\WINDOWS\system32> -
@bob-dig said in 2.5 connecting via hostname not working across interfaces:
and my windows is not new. Host file is empty on it,
The host file on windows == don't care.
I was talking about the hosts file of pfSense.Make your Windows IPv4 DHCP "domain name aware" :
-
@gertjan Thanks for the solution.
Although it was not the point of my posting.
-
@bob-dig said in 2.5 connecting via hostname not working across interfaces:
@gertjan Thanks for the solution.
Although it was not the point of my posting.Ah, yes, the issue :
@bob-dig said in 2.5 connecting via hostname not working across interfaces:
I used to connect RDP via hostname, this has always worked for me with 2.4.5.
Now with a fresh 2.5 it works only on the same interface.Check :
Can you actually connect from 'a network' to 'another network' : check your firewall wall rules on the 'a network' interface.
Also : the system you RDP to accepts connection form the 'a network' ? and not only from its own network ?I didn't detect any changes. I can still RDP into my 'local' systems using aremote VPN access etc.
-
@gertjan RDP just works fine via FQDN, so it is the pfSense DNS-Resolver which now behaves differently, thanks to all our testing, I would say.
-
@bob-dig said in 2.5 connecting via hostname not working across interfaces:
DNS-Resolver which now behaves differently
Again what version of pfsense were you on?? 2.3.3 fixed the problem of resolving just hostnames.
https://docs.netgate.com/pfsense/en/latest/releases/2-3-3.html#dns-resolver-forwarder
Changed behavior of DNS Resolver overrides to only add FQDN entries, not short hostnames #6064That was Feb of 2017
-
@johnpoz 2.4.5.p1, as I said, always the latest. So you say, it is not a bug, it is feature? I can't quite see it, but good to know.
I think I started with pfSense with 2.4.4., but not sure exactly.
The other change is I now use a gen2 VM instead of a gen1 VM and another NIC (Hyper-V). -
It resolving just hostname was a bug yes.
dns - to resolve it must be fqdn.
-
Or another thing that could be the culprit would be the DHCP Domain added to your client. If that changed in your new install of 2.5 or you added VLANs and used different Domain parts in DHCP for those (vlan1.home.arpa, vlan2.home.arpa, lan.home.arpa etc) and/or your windows client didn't get the domain search path (or a new one), a lookup of "nslookup <name>" won't get resolved anymore. With domain search path set to "home.arpa" that should be extended to "<name>.home.arpa" and if that won't exist or is unknown to unbound, that won't get you far. I think there was some bug/problem with DHCP and different default domains or search paths per VLAN but I'm not entirely sure ;)
But setting the domain search path in DHCP (or manually adding the suffix as Gertjan pointed out on the client itself) should let Windows resolve hostnames only
-
@jegr Definitely did none of those things before and now.
But RDP-Client is very sticky with targets anyway so there will be no discomfort once I have all of them in there and I deleted all hostnames.
