Lan's ip is 254, and the web page cannot be accessed

UClinux

Environment: Install pfSense-CE-2.6.0 and pfSense-CE-2.7.0 respectively for testing

In the console interface, select
2) Set interface(s) IP address
After setting the lan interface ip to 192.168.x.254/24, the ip can be pinged on any computer in the LAN, but the web login page cannot be accessed.

After trying to execute pfctl -d, the web cannot be accessed
Try to restore the factory settings, set the ip to 192.168.x.254/24, the web cannot be accessed
Netstat -4an checks that port 80 is open, and the test telnet is normal, but 443 is not open. Of course, I also try to access http, but the web cannot be accessed
If you change the ip to 192.168.x.(1-253)/24, everything is normal, and there is no problem accessing the web login page

why is that?

bingo600

There's an automatic "Antilockout rule on Lan" , it might only be active for .1 access.
Try to make an additional rule allowing the same for .254 before switching.

Or ssh to the box , and restart the webgui service.

/Bingo

stephenw10

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

If you change the ip to 192.168.x.(1-253)/24, everything is normal,

The sounds like there is already a device using .254 on the subnet.

johnpoz

@bingo600 said in Lan's ip is 254, and the web page cannot be accessed:

it might only be active for .1 access.

That wouldn't make any sense to do.. And that anti lockout rule specifically calls out lan address, so whatever this would be what the rule allows traffic to the ports being used for the gui and ssh (if enabled)

I would think maybe dupe IP issue, validate the mac is correct for pfsense lan interface in your clients arp table.

UClinux

Today I did the test again, trying to migrate the test environment from vds to another esxi host without a vlan network, the port group is tested with a local standard switch, and the client is also changed to another win system. x.254 is accessible.
Then I migrated back to the original vds network environment vlan 222, and the original win client system.
Test again, x.254 web cannot be opened.
Guess the problem should be in the browser (third-party browser based on Chromium kernel),
Close the browser, start the browser in safe mode, and the x.254 web can be accessed.
Close the browser again, open it in normal mode, and clear all cache records of the browser. x.254 web accessible

So far, the cause of the problem is the browser cache problem

Actually, before that,

I have tried to use the privacy mode of the browser to visit, but the x.254 web has been unable to open
I also copied the new version of chrome to this client system (win81), but it cannot run, and Google no longer supports it. Did not continue to download the old version. . .

In retrospect, the reason may be that before the pfsense test host was built, this browser visited an x.254 pfsense main gateway, using https,
After the pfsense test host is installed (the pfsense main gateway Lan interface is disabled), use this browser to access x.254. The browser forcibly jumps from 80 to 443 due to cache reasons, but the pfsense test host is newly installed, and https has not been enabled by default. (443).
Of course, I also tried http://192.168.x.254:80/ and it couldn't be opened.

I've tested in privacy mode, so I don't think it's a cache issue. . .
This third-party browser privacy mode is to open another tab, unlike Google Chrome, which is to open another browser. So the privacy mode is not reliable

Several reasons combined to lead to this test result. . .

Thank you friends

JonathanLee

@yjd run Arp -a and check what Mac addresses map to what IP from the console. Make sure you do have have any duplicates. Broadcast address?

Have you plugged in this address scheme into a subnet calculator? With the cider notation /24 network some addresses are set aside for broadcast, multicasting etc. Subnet calculator will display what address pool you can use.

Just double check it. I see you have X for the 2nd octet so plug in what you are using to make sure.

Gertjan

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

Set interface(s) IP address
After setting the lan interface ip to 192.168.x.254/24, the ip can be pinged on any computer in the LAN, but the web login page cannot be accessed.

Normally, right after the LAN IP (and network /24 ?) has been changed, you should also check / modify the LAN DHCP server page, and save over there.

Then : if you're more a 'manual' guy : remove the LAN cable from your device for a couple of seconds.
Or disable de Wifi for a couple of seconds, and re enable, re connect.
Or do something like this on your device :

ipconfig release
ipconfig /renew
ipconfig /all

Check the output of the last command, and see if everything looks fine.
Notably : the gateway and DNS should now show the right IP : .254

Tip of the day : when you do a network setup, be ready to use 'another' browser, like (windows 8) Edge or IE. At least, none of your issues will be cache issues.

UClinux

@JonathanLee
x stands for 2, 222, 1. I tested it many times yesterday, and thought it was a 2.7 bug and tried to reinstall the 2.6 test.
No typo issues.

As mentioned at the beginning of the topic, on this client system that cannot access x.254, the x.254 ip can be pinged normally. If the address is written wrong, it will fail to ping

UClinux

@Gertjan
You mentioned manually refreshing the ip, I have tried it, and I often disable and re-enable the network card during the test. The main reason is that I believe too much in the privacy mode of the browser, so I did not try to change ie and firefox for testing.
Lessons must be learned. In the past, I usually give priority to clearing the cache and testing again. . .

Gertjan

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

reason is that I believe too much in the privacy mode of the browser, so I did not try to change ie and firefox for testing.

Strange. We use different info sources then. I would prefer Firefos far over edge or the chrome thing. The last two have just one main mission : transmit everything you do to their creator. Showing a web page is their second role

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

disable and re-enable the network card during the test

Always check afterwards your DNS/gateway IP.
You can stop checking as soon as you're done designing your network.

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

I usually give priority to clearing the cache and testing again. . .

If you visit a web page on 192.168.1.1 (so 192.168.1.1 is the URL) - and then you visit a device at 192.168.1.254, then there will be no cache involved, as it is not the same device neither the same web server (in theory - this time it is, as you've changed the IP of the web server device).

@yjd said in Lan's ip is 254, and the web page cannot be accessed:

to clearing the cache

Remember this one :

ipconfig /flushdns