(solved) 2.5 connecting via hostname not working across interfaces

Bob.Dig

@johnpoz No, just installed pfsense from the get go. Don't know why it worked before.

johnpoz

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=64

See how it comes back fully qualified while just using nas.. Because the OS is auto adding local.lan when it does the dns query..

Bob.Dig

@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.

Gertjan

@bob-dig

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.

Bob.Dig

@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.

Gertjan

@bob-dig

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 device

It 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.

Bob.Dig

@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:

Gertjan

@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.2

From 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.2

Probably because my Windows prefixes (appended ?) the local domain name.

Bob.Dig

@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>

Gertjan

@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" :

Bob.Dig

@gertjan Thanks for the solution.
Although it was not the point of my posting.

Gertjan

@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.

Bob.Dig

@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.

johnpoz

@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 #6064

That was Feb of 2017

Bob.Dig

@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).

johnpoz

It resolving just hostname was a bug yes.

dns - to resolve it must be fqdn.

JeGr

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

Bob.Dig

@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.

Bob.Dig

Meanwhile it is working like in the past, hostname only connecting without a problem, although ubound still couldn't answer. Maybe a windows "feature".

Probably not related to pfSense in the first place.

johnpoz

@bob-dig said in [solved] 2.5 connecting via hostname not working across interfaces:

hostname only connecting without a problem

Your either doing discovery - which would be same L2, or your windows clients are adding suffix like they are suppose to..

Sorry but it is not possible to do discovery, be it broadcast, multicast, LLDP, WSD, etc. across vlans.. For dns to respond the query has to be fully qualified.

You running an old school WINS ;)

example... Here I only ask for sg4860, but you see the actual query sent via nslookup is sg4860.local.lan.. Because windows has that as its search suffix.

C:\>nslookup
Default Server:  pi-hole.local.lan
Address:  192.168.3.10

> set querytype=A
> set debug
> sg4860
Server:  pi-hole.local.lan
Address:  192.168.3.10

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        sg4860.local.lan, type = A, class = IN
    ANSWERS:
    ->  sg4860.local.lan
        internet address = 192.168.9.253
        ttl = 3547 (59 mins 7 secs)

------------
Non-authoritative answer:
Name:    sg4860.local.lan
Address:  192.168.9.253

>

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : I5-Win
   Primary Dns Suffix  . . . . . . . : local.lan
   Node Type . . . . . . . . . . . . : Broadcast
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : local.lan