(solved) 2.5 connecting via hostname not working across interfaces
-
-
@bob-dig
I knew it. The question sounded familiar
-
I have to bring that up because it is an ongoing problem. Sometimes it works over other interfaces, sometimes it doesn't.
-
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.
-
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.
-
Are you IPs changing? This isn't freaking rocket science ;) But it does require some basic understanding of dns and networking..
-
@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.
-
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..
-
@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. -
@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.
-
@johnpoz It worked for some time... but it is probably the reason for the latest problems.
-
I once again had to reinstall a fresh pfSense and guess what is not working again, RDP only via hostname.
But it seems related to using DHCP on my Windows. If I am using DHCP for IPv4, I can connect via hostname. If I dial-in the same settings manually, I only can connect via FQDN.
So it is all a windows "thingy". Weird but now I know at least this. -
@bob-dig You can not resolve just hostname unless you are on the same L2 and broadcast for it.
If you actually setup your network correctly be able to resolve everything via FQDN, and your window devices would auto add the domain your using locally via domain suffix.
This is a layer 8 issue...
-
@johnpoz said in (solved) 2.5 connecting via hostname not working across interfaces:
This is a layer 8 issue...
I got you.
But there is still one missing puzzle peace. Why the heck it will work after some time (weeks), even if I dialed in the settings my self only in the first window of the IPv4 Properties, missing out on the DNS suffix field? Only Windows knows.
-
@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..
-
@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?
-
@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=64Here is it doing the fqdn query, even though I only used nas
suffix
-
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 :)
-
@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. -
@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.
