VMs inaccessible by hostname after doing changes to network

[Octopuss]

I have a server running ESXi 6.7 that houses a vCenter management, TrueNAS, (Ubuntu) seedbox, and until today pfSense VMs.
I have finally installed the pfSense box and shut the VM down, and changed the network a bit during the process.
The entire LAN is still the same: 192.168.0.1/22, domain is "lan".
The IPs changed like so:
server: 192.168.2.1 -> 192.168.0.3 (was previously static to IP), hostname "ESXi"
vCenter: 192.168.2.3 -> 192.168.0.4, hostname "vCenter"
NAS: 192.168.2.5 -> 192.168.0.7, hostname "Skladiste"
seedbox 192.168.2.6 -> 192.168.0.8, hostname "seedbox"
With the exception of the server itself, everything was already set to static DHCP mapping before, I only changed the IPs.

Now it's all messed up. Or well, everything that is related to the damn server, or so it seems.
Hostnames just don't work. IPs seem to do, but it's weird.
When I try to access the vCenter by IP, I get as far as this

but when I click on the first option, the page times out, because it redirects to "vcenter.lan".

TrueNAS is even weirder.
It works fine by IP, but hostname doesn't work, and I can ping the VM by hostname, only it looks like this:

I have no idea where the local domain came from. "skladiste.lan" doesn't work.

Accessing Webmin on the seedbox, again, only works by IP.


I know very, very little about networking, and this is something I am absolutely unable to troubleshoot.
Can anyone think of anything?

 

[Rand__]

Whyever u use a /22 with no networking experience and 6 hosts
But thats not the issue

U booted the switch (toclear the arp cache?)
Whats your new DNS, DHCP default gw?

Are you using host files?

 

[Octopuss]

Nevermind the first part, I suspect the result would be the same.

What do you mean I booted the switch? Of course I booted it, it's running. I don't understand the question. No idea what arp cache is.

Everything runs off pfSense now, so 192.168.0.1.

No, I don't.

 

[Rand__]

I mean rebooted the switch so it would unlearn the old mappings.

How you set the domain name to .lan? I assume u don't have a domain controller running? So you just assume its .lan?
Or you set a fqdn (skladiste.lan) on each host with in the ethernet config? And then added that name to DNS on pfsense?

 

[Octopuss]

Oh. Sure I did. Several times.

I set the domain name within pfSense.

 

[Rand__]

so what happens if u run nslookup or dig on short or long name?

skladiste seems to think its domain is .local, so that does not seem to be set correctly (usually in /etc/hosts)
IP address hostname [hostalias]...

192.168.0.7 skladiste skladiste.lan

Edit:
if you used DHCP you would set it there. DNS needs to match local settings (and vice versa o/c)

 

[louie1961]

I believe it is a pfSense issue, specifically if you are using Kea DHCP. Try deactivating Kea DHCP and reverting to the old DHCP module (I forget the name of it in pfSense). I had the same problem when I switched my pfsense to a new box due to an upgrade. its weird, but I believe Kea DHCP is still buggy and not ready for primetime.

 

[Octopuss]

so what happens if u run nslookup or dig on short or long name?

skladiste seems to think its domain is .local, so that does not seem to be set correctly (usually in /etc/hosts)
IP address hostname [hostalias]...

192.168.0.7 skladiste skladiste.lan

Edit:
if you used DHCP you would set it there. DNS needs to match local settings (and vice versa o/c)

Sorry I don't understand you. I have no idea what "to dig on short names" mean. If you're using some kind of slang, I am not a native english speaker.

I never set anything on skladiste, everything was always done via DHCP.
hosts seem to be ok?


Run nslookup from where? What is it anyway? I vaguely remember the name.

 

[Octopuss]

so what happens if u run nslookup or dig on short or long name?

skladiste seems to think its domain is .local, so that does not seem to be set correctly (usually in /etc/hosts)
IP address hostname [hostalias]...

192.168.0.7 skladiste skladiste.lan

Edit:
if you used DHCP you would set it there. DNS needs to match local settings (and vice versa o/c)

Sorry I don't understand you. I have no idea what "to dig on short names" mean. If you're using some kind of slang, I am not a native english speaker.

I never set anything on skladiste, everything was always done via DHCP.
hosts seem to be ok?
View attachment 34632

Run nslookup from where? What is it anyway? I vaguely remember the name.

 

[Octopuss]

I believe it is a pfSense issue, specifically if you are using Kea DHCP. Try deactivating Kea DHCP and reverting to the old DHCP module (I forget the name of it in pfSense). I had the same problem when I switched my pfsense to a new box due to an upgrade. its weird, but I believe Kea DHCP is still buggy and not ready for primetime.

Hm, that didn't change anything.
I changed it, rebooted pfSense, rebooted the switch, rebooted the server, and nothing.

 

[BobTB]

Your DNS is mixed up. You have some .local and some .lan domains. decide what to use and set all to be the same.

 

[Octopuss]

Your DNS is mixed up. You have some .local and some .lan domains. decide what to use and set all to be the same.

I don't. Where did you get that from? I specifically wrote I set the domain to "lan" in pfSense. There is no other place where I'd set it.
That's not even the root of the problem.

 

[Rand__]

dig is a command on linux. as is nslookup (and also on windows) - looks up names from ips or vice versa
short name is the hostname without domain
long name is the fqdn (fully qualified domain name, ie. host.domain....)

Previously you used DHCP which sets values, now you have static IPs...

 

[Octopuss]

The only static IP is the switch. I said so.
I do have static DHCP mappings though, but that's still DHPC assigning IPs.

What exactly am I supposed to do with dig and nslookup then? I am not a command line person.

 

[Rand__]

With the exception of the server itself, everything was already set to static DHCP mapping before, I only changed the IPs.

Ok, so you have DHCP reservations for each host, now i understand that.
And in the DHCP config you also set the domain name to .lan?

dig/nslookup are meant to see what the DNS is actually finding for your IP addresses to name or Name to IP adresss resolution

similar to your ping attempt where it resolved to skladiste.local instead of .lan
That means that the shortname is incorrectly completed, the question is why and by what. that can be host, dns or dhcp

 

[Octopuss]

Yes! That's what I meant.
I don't have domain set in DHCP because it's redundant. It uses what the system is set to if empty, the point of the field is to be able to override it for whatever reason.

What machine should I run the commands from then, and what should I look for? Sorry, this is just confusing to me.

 

[Rand__]

any client will do

try short name, long name1,2 and ip
so
nslookup skladiste
nslookup skladiste.local
nslookup skladiste.lan
nslookup 192.168.0.7

 

[Octopuss]

I tried from Windows then.


Eeeee, what...? That makes no sense.

 

[Rand__]

have you set domain name server (DNS) and default gw?
probably in dhcp server to promote to all boxes?
or in network config on each box?

also that seems as if it does not auto attach a default search domain (.lan)

also is dhcp updating your dns? or have you set static dns entries?

 

[Octopuss]

Yes I do have default gw set but that's only relevant to internet, I'm trying to figure out local stuff, right?
No idea wha promote all boxes mean

I think this is hopeless, I don't understand 80% of what you say.