Access to GUI lost after changing LAN IP

markagregory

Environment: ESXi 7.02U Loading pfsense as a VM and connecting it to virtual switches with no physical adapters.
After setup with all defaults can access GUI. Also client machines on LAN can ping and connect. Cannot ping pfsense LAN IP.
the next step is to change the pfsense LAN IP from 192.168.1.1/24 to 10.10.50.1/24
At this point the clients attached to the LAN can still ping each other. Access to the GUI is lost. Cannot ping pfsense LAN IP.

using pfsense, can PING WAN gateway, but cannot ping LAN clients.

Have googled and this still appears to be a major problem with pfsense. Would appreciate ideas on what is happening and why

Gertjan

@markagregory said in Access to GUI lost after changing LAN IP:

Have googled and this still appears to be a major problem with pfsense

This : Virtualizing pfSense Software with VMware vSphere / ESXi doesn't tell me that it doesn't or can't work.
What others say : well .... it' a free world after all

I've no numbers, but I'm pretty sure there are many thousands out there using pfSense on ESXI right now.

When using pfSense (software you can download) on a VM like ESXI (something you can download) you might think that all is needed are some clicks.
Wrong : a lot of knowledge is needed. You have to 'download' that also ^^

@markagregory said in Access to GUI lost after changing LAN IP:

Also client machines on LAN can ping and connect. Cannot ping pfsense LAN IP.

Show the pfSense LAN firewall rule(s) .It's very possible that you permit TCP and UDP but not ICMP. That explains why 'PING' doesn't reply.
The default LAN rules permits all traffic, and that includes PING.

@markagregory said in Access to GUI lost after changing LAN IP:

the next step is to change the pfsense LAN IP from 192.168.1.1/24 to 10.10.50.1/24
At this point the clients attached to the LAN can still ping each other. Access to the GUI is lost.

You forgot to mention something.
'Clients' use DHCP, and are not aware that you changed the gateway/DNS IP ....
Normally, you could ripe out the network cable or a moment, reconnect and by magic (DHCP actually), everything works again.
Now you have to execute a

ipconfig /renew

on the client, if it is a Windows PC.
And of course, becaus eyou like to check :

ipconfig /all

and there you'll see that now the LAN client has a new IP, in the 10.10.50.0/24 range, and that the gateway has been set to 10.10.50.1 like the DNS.

markagregory

@Gertjan thank you for responding.

my setup now is

LAN 192.168.1.1/24
OPT1 10.10.50.1/24
OPT2 10.10.51.1/24
OPT3 10.10.52.1/24
OPT4 10.10.53.1/24

I've learnt the following:

not to change the LAN IP - I'm using this as a management subnet to connect with pfsense
LAN - I have not changed this
OPT1 I copied the rules from LAN (and similarly to OPT2, OPT3, OPT4)
I can ping 192.168.1.1 from a VM on LAN
I can ping between two VMs on OPT1
I cannot ping 10.10.50.1 from a VM on OPT1
I cannot ping a VM on OPT1 from pfsense using diagnostics ping
I need to be able to route between traffic from VMs on OPT1, OPT2, OPT3, OPT4 - help appreciated

johnpoz

@markagregory lan subnet would never be inbound source into your opt1 network.. The only network unless opt1 was a transit network that could be realistic source would be the opt1 subnet.

Not being able to ping something on the opt1 network points to a firewall on that device, or maybe it has the wrong mask? And thinks pfsense IP is not on its netwtork.. with and address of .135 for example if it had a mask of /25 then no .1 wouldn't be on its network because the network it would be on if it was 10.10.50.135/25 would be 10.10.50.128 - 10.10.50.255

Do you see the mac address of .135 in the arp table after you try that ping command? If not then no you would never in million years be able to ping .135.. If you do have a mac, is the correct one? If so then pfsense put the traffic on the wire - not getting an answer is out of pfsense control.

What rules you have on opt1 has nothing to do with pfsense being able to ping something on opt1, it would have to do with devices on opt1 being able to ping pfsense opt1 address or anything else for that matter.

markagregory

UPDATE:

I decided to check the interfaces for the third time, and I found that all of the OPT interfaces were jumbled - yet again.

I fixed the interfaces again according to the mac address for each interface in the VM settings.

this time, I did not reboot pfsense.

Now everything is working as expected.

I'm going to start to restrict the traffic from WAN to LAN, but for now, all of the VMs connected to OPT1, OPT2, OPT3 and OPT4 can ping each other and the pfsense interfaces.

It may be easy to say that it was a simple setup mistake, but I checked my work log and what I set on three occasions was changed on three occasions - once during the initial setup and each time I added interfaces to the VM (two occasions - all had a reboot at the end).

I've learnt to check the interfaces every time I do something on the VM config side.

Also, I've learnt not to change the LAN settings - this cost me two days of going around in circles before I decided to leave the LAN alone and add OPT1, OPT2, OPT3, and OPT4

After all this, I think pfsense looks great, thank you to everyone that has provided some input. I have other questions, but I'll start googling before I ask here.

johnpoz

@markagregory said in Access to GUI lost after changing LAN IP:

ach time I added interfaces to the VM (two occasions - all had a reboot at the end).

Yeah adding interfaces to esxi can do that, its a esxi thing from what I recall. If you search you will find multiple threads on it.

Here was a freebsd bug on it

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198406

Doesn't seem to have gotten any traction.. I don't think its actually a freebsd problem

https://forum.netgate.com/post/442381

stephenw10

Yup that's a fun* one!
More than 4 vmx NICs in esxi changes the PCI device ordering. Crazy.