(solved) 2.5 connecting via hostname not working across interfaces

Bob.Dig · Mar 1, 2021, 11:46 AM

@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 · Mar 1, 2021, 11:42 AM

It resolving just hostname was a bug yes.

dns - to resolve it must be fqdn.

JeGr · Mar 2, 2021, 8:22 AM

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 · Mar 2, 2021, 8:32 AM

@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 · Mar 10, 2021, 6:38 PM

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 · Mar 10, 2021, 6:50 PM

@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

Bob.Dig · Mar 10, 2021, 6:58 PM

@johnpoz It is still looking different here:

PS C:\WINDOWS\system32> nslookup
Default Server:  pfSense.home.arpa
Address:  192.168.1.1

>  set querytype=A
>  set debug
> mail
Server:  pfSense.home.arpa
Address:  192.168.1.1

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

    QUESTIONS:
        mail, type = A, class = IN
    AUTHORITY RECORDS:
    ->  (root)
        ttl = 612 (10 mins 12 secs)
        primary name server = a.root-servers.net
        responsible mail addr = nstld.verisign-grs.com
        serial  = 2021031001
        refresh = 1800 (30 mins)
        retry   = 900 (15 mins)
        expire  = 604800 (7 days)
        default TTL = 86400 (1 day)

------------
*** pfSense.home.arpa can't find mail: Non-existent domain

PS C:\WINDOWS\system32> ipconfig -all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : U5
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : home.arpa

Really have no clue why it is working again and not before.

Gertjan · Mar 11, 2021, 7:40 AM

@bob-dig

My turn :
I don't have a local host name called 'mail', but I have one called 'diskstation2' :

C:\Users\Gauche>nslookup
Serveur par dÚfaut :   pfsense.my-domain.net
Address:  2001:470:1f13:5c0:2::1

> set querytype=A
> set debug
> diskstation2
Serveur :   pfsense.my-domain.net
Address:  2001:470:1f13:5c0:2::1

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

    QUESTIONS:
        diskstation2.my-domain, type = A, class = IN
    ANSWERS:
    ->  diskstation2.my-domain.net
        internet address = 192.168.1.33
        ttl = 3600 (1 hour)

------------
Nom :    diskstation2.my-domain.net
Address:  192.168.1.33

>

C:\Users\Gauche>ipconfig -all

Configuration IP de Windows

   Nom de l’hôte . . . . . . . . . . : Gauche2
......
   Liste de recherche du suffixe DNS.: my-domain.net

Carte Ethernet Ethernet :

   Suffixe DNS propre à la connexion. . . : my-domain.net
   Description. . . . . . . . . . . . . . : Intel(R) Ethernet Connection (11) I219-LM
   Adresse physique . . . . . . . . . . . : A4-BB-AC-BA-16-A1
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6. . . . . . . . . . . . . .: 2001:470:beef:5c0:2::c7(prefered)
   Bail obtenu. . . . . . . . . . . . . . : mercredi 10 mars 2021 06:51:57
   Bail expirant. . . . . . . . . . . . . : jeudi 11 mars 2021 10:04:47
   Adresse IPv6 de liaison locale. . . . .: fe80::410c:5e0d:e1a1:6075%10(prefered)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.6(prefered)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : mercredi 10 mars 2021 08:18:04
   Bail expirant. . . . . . . . . . . . . : vendredi 12 mars 2021 00:38:52
   Passerelle par défaut. . . . . . . . . : fe80::215:17ff:fe77:d118%10
                                       192.168.1.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
   IAID DHCPv6 . . . . . . . . . . . : 111459181
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-26-AC-DF-8D-BB-BB-6D-BA-16-A1
   Serveurs DNS. . .  . . . . . . . . . . : 2001:470:1f13:5c0:2::1
                                       192.168.1.1

Your 'unbound' doesn't know it lives in "home.arpa" so it should (should it ?) try also
mail.home.arpa
which should be in the /etc/hosts file on pfSense, thus known to unbound, as it reads /etc/hosts at start-up.
IF not, give that host called 'mail' a static DHCP MAC lease **, or host override it on the unbound settings page.

** and keep this checked :

edit : I'm not using a domain like "home.arpa". As I need known 'cert' on my LAN, I use a 'real' (rented) domain name for internal uses and acme. I don't think that difference matters.

My unbound knows that :diskstaion2 is local, as it is definced in /etc/hosts/

.....
192.168.1.33	DiskStation2.my-domain.net DiskStation2
....

Strange to see that unbound even bothers a main root server with a non valid host name like 'mail'.

Bob.Dig · Mar 11, 2021, 7:42 AM

@gertjan Bonjour.
They all got a static mapping and this box is checked all the time.
So still no clue why this behavior changed and now has changed again.
C’est la vie...

Gertjan · Mar 11, 2021, 8:08 AM

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

C’est la vie...

Coté fichier /etc/hosts : toutes tes hôtes y figurent ?

Bob.Dig · Mar 11, 2021, 8:15 AM

@gertjan I think we were there already.
Adieu

Gertjan · Mar 11, 2021, 8:33 AM

@bob-dig

I knew it. The question sounded familiar

Bob.Dig · Apr 4, 2021, 10:28 AM

I have to bring that up because it is an ongoing problem. Sometimes it works over other interfaces, sometimes it doesn't.

Bob.Dig · Apr 4, 2021, 5:25 PM

I enabled Register DHCP leases in the DNS Resolver in addition to the already enabled Register DHCP static mappings in the DNS Resolver and now it is working again, before even FQDN wasn't working. It is a mess.

Bob.Dig · Apr 7, 2021, 6:07 PM

I noticed that sometimes my windows can't connect even if via ip it is possible and even the dns resolution is working according to nslookup. It is making no sense to me.

johnpoz · Apr 7, 2021, 6:21 PM

Are you IPs changing? This isn't freaking rocket science ;) But it does require some basic understanding of dns and networking..

Bob.Dig · Apr 8, 2021, 8:04 AM

@johnpoz They don't change but the windows smb shares don't work anymore, unreachable, although via IP it is working.
But I don't know what the reason is, an ARP problem maybe? It is two Windows PCs across different interfaces.

But I just noticed that the problem was different when I started this thread. It somehow looks related to me but it might not be.

johnpoz · Apr 8, 2021, 9:53 AM

Well troubleshoot the problem - if its not working via IP, it has zero to do with name resolution.

Sniff - what happens.. Does pfsense send on the syn.. Then its not pfsense..

Bob.Dig · Apr 8, 2021, 1:10 PM

@johnpoz It always does work with IP, names some of the time.
But to my later problem, I had ACL one machine to use the resolver only for local stuff. Maybe windows will not use it anymore and will favor the other... hard to tell. I switched to ip and will stay there, at least in that vm.
The original problem, RDP just over the hostname seems gone, it always works so, even across interfaces.

johnpoz · Apr 8, 2021, 1:10 PM

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

I had ACL one machine to use the resolver only for local stuff.

Huh? How exactly do you think that could work? While sure you can set the ACL to only be able to resolve local stuff. How would that client then resolve public stuff? You can't just point a client to 2 different NS that resolve different things and not have problems.