(solved) 2.5 connecting via hostname not working across interfaces

johnpoz · Jul 1, 2021, 1:47 PM

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

missing out on the DNS suffix field? Only Windows knows.

Huh?? Sorry I can not make any sense of that... You either broadcast for a hostname, or you resolve a fqdn.. There is no "puzzle" to it..

Bob.Dig · Jul 1, 2021, 1:47 PM

@johnpoz said in (solved) 2.5 connecting via hostname not working across interfaces:

There is no "puzzle" to it..

Riddle me this. Why is it for some time not working and later it is?

johnpoz · Jul 1, 2021, 2:08 PM

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

Riddle me this. Why is it for some time not working and later it is?

Have no freaking idea what your setup is... I can tell you this - YOU CAN NOT resolve a hostname from dns, it has to be fully qualified... That is how dns works.

I have no idea what your actually doing, or how your network is setup or what your trying to resolve and how.

For all we know why it some times worked and sometimes didn't is you had your client pointing to 2 different dns, and when it asked pfsense for host.domain.tld it worked, and when it asked your external dns it failed because it has no clue to your local domain.

You can not control what NS a client might ask when there is more than one..

What I can tell you is if setup correctly you could always resolve all your resources via just putting in a hostname because the client would auto added the suffix for whatever domain your using locally.. And now you have zero issues and can always resolve..

here I just put in nas, and it actually resolve the fqdn nas.local.lan because my client auto does that dns lookup by auto adding the suffix.

C:\>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

Here is it doing the fqdn query, even though I only used nas

suffix

JeGr · Jul 1, 2021, 2:56 PM

Someone can call me names, but I guess it could be simple Windows doofus magic. I'd be guessing that it works after

device was in the same L2 (e.g. at home)
device did a check for <name>
device got an answer for <name> as it's on the same l2 network and/or DNS is configured correctly
device goes on adventure and dials in via VPN
device still has DNS/name cached in applications and system
device rebooted/cleared - device no longer able to resolve name without fqdn.

If the local DHCP submits a correct DNS search path and default domain and OpenVPN is configured to match that, simple name resolution should work either way as the client should always attach its primary domain suffix/default domain to a "name only"

It's difficult though if your e.g. laptop is in a windows domain (work) and you take it home. Even though it's pushed via DHCP windows can be stubborn and add your AD domain as default to any hostname-only things.

So yeah, that can very well be a windose problem :)

Gertjan · Jul 1, 2021, 4:05 PM

@jegr said in (solved) 2.5 connecting via hostname not working across interfaces:

If the local DHCP submits a correct DNS search path and default domain ....

So yeah, that can very well be a windose problem :)

If we use Windows, we all use the "20H1 Pro version", right ?

From what I know :
The pfSense DHCP server hands over many 'options', and one of it is the DNS domain search option' :

Liste de recherche du suffixe DNS.: my-local-domain.net

(Sorry for the non native language)

This, me doing NOTHING on a (new) PC : I hook it up, and everything works.

All of this can be checked by packet capturing (the DHCP negotiation).
DNS traffic from a PC doesn't query a host like ': what is the A record of 'nas' ?
'nas' isn't a valid 'URL' here - it must have the FQDN format.
It won't break 'DNS' rules (I guess, as a 'get lost' reply will follow).
It will ask for "nas.my-local-domain.net" - this is a FQDN, and the resolver can handle that request just fine.
It even knows that it shouldn't bother the 'root' servers with this request, as it knows that this request is (and stays) local : my-local-domain.net.

Btw : this is how I think it works, as it makes a lot of sense.
Also : I'm talking about a 'new Windows device', never 'touched' by some one - and a 'default' pfSense installation : it's plug and play.

Bob.Dig · Jul 1, 2021, 4:49 PM

@Gertjan Yes you are right. That is why it is working if I am using dhcp from pfSense and why it is not working when I dial in my settings only in the first window of the IPv4 settings, without going deeper for filling in DNS suffix field.

You also can see this with ipconfig -all, the suffix is missing.

@johnpoz And there is no second DNS Server, only pfSense. The second DNS-Server is long gone, we had talked about it and you where right with that.

And this is what I don't get, why it will work after some time (could be weeks, month maybe) anyways. I don't use openVPN on my Windows machine.
I have absolute no clue. That is the puzzle for me. Anyways, I am sure it has nothing to do with pfSense and we can close this now for good.

johnpoz · Jul 1, 2021, 7:10 PM

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

why it will work after some time (could be weeks, month maybe) anyways.

Well troubleshoot it... When it doesn't work - why doesn't it work... You can instantly tell from a simple ping if it came back by broadcasting when it doesn't come back fully qualified..

Your never going to figure out anything just wondering about it - its not rocket science here there are only so many ways to resolve a name to an IP be it fully qualified or not or dns query..

But no your never going to understand anything on why something does or doesn't work if you don't actually understand the method your using to resolve or not resolve.

If I put in just nas and it doesn't come back fully qualified and the IP I know my name resolution is failing. But until look into not exactly sure why - did my client no longer send the correct domain, did my dns not answer, does my dns not have that record in there and sent back nx, or servfail, etc. etc.

edit: Maybe your trying to hit something up in your browser - and yoru browser decided to F whatever you doing locally and ask xyz dns via doh.. etc.. Because just ask the browser makers - users are too stupid to be able to run their own dns and resolve what they want how they want.. So since they know better and could switch from your local dns to theirs on a whim ;)