[SOLVED] No access to pfSense webgui (suddently) but SSH works, other clients in VLAN can access

LaUs3r

Guys,

I am fully lost in the woods.

Suddenly I cannot access my pfSense webgui anymore from my main PC (192.168.10.3, VLAN 10).
My pfSense is on 192.168.0.1 (port 80)

On my client (192.168.10.3) --> pfSense (192.168.0.1):

webgui: http://192.168.0.1:80 endless loading, no timeout message (Firefox, Chrome, Edge - also in private Tab)
SSH: OK
PING: OK
Powershell: test-netconnection 192.168.0.1 -Port 80: TcpTestSucceeded: True
tracert: 1 hop < 1ms
no Windows firewall rule (disabled fw)

Troubleshooting so far without success:

added pfSense rule to allow 192.168.10.1/24 to 192.168.0.0/24 (any ports, any protocol) just to make sure really nothing is blocked
assigned different IP to my mainPC and tested connection: not working
used different PC in the vlan 10 (VM with 192.168.10.12 sharing my main PCs network adapter = bridged mode), here webgui works = VLAN per se ok
compared routes of mainPC and VM: are the same
other webGUIs on 192.168.0.1/24 are reachable from main PC (for example 192.168.0.4)
restarted pfSense webGUI
restarted pfSense
restarted mainPC

Configs:

pfSense Plus: 24.11-RELEASE (latest)
mainPC: Windows 11, Firefox (latest)

Any advice where to look any further?

stephenw10

I assume pfSense has an interfaces in VLAN10? Can you reach the webgui on that IP? 192.168.10.1 perhaps?

The webgui listens on all IP addresses on the firewall so you should be able to reach it as long as firewall rules allow it.

Otherwise anything that might dynamically block your client would block the IP for all services.

I would run a pcap on VLAN 10 for traffic from your client IP and make sure the http requests are actually arriving.

Also why are you using http and not https?

LaUs3r

@stephenw10 , thx.
I tried now the most obvious thing and booted my PC with a live Ubuntu. Therefore I get the same IP settings from my pfSense DHCP.
With Linux I can access the webgui without problems.

This makes me assume that my win11 settings are somehow corrupt.

Before now resetting my PC or removing manually updates, would you have other suggestions?
I already disabled the firewall and AV.

netstat shows a TCP connection on 192.168.0.1 port 80 on my PC. I just have the feeling that the packages from pfSense are not handled correctly on my PC

Btw. changing to https didn't change anything.
Connection to the vlan gw does not work either (192.168.10.1)

This is what I got from the pcap:

Running packet capture:
/usr/sbin/tcpdump -ni ix0.10 -c '1000' -U -w - '((host 192.168.0.1)) and ((not vlan))'

18:13:14.921601 IP 192.168.0.1.80 > 192.168.10.3.57339: tcp 5043
18:13:24.501554 IP 192.168.10.3.57339 > 192.168.0.1.80: tcp 1
18:13:24.501651 IP 192.168.0.1.80 > 192.168.10.3.57339: tcp 0
18:13:24.501736 IP 192.168.10.3.57339 > 192.168.0.1.80: tcp 0
18:13:27.022080 IP 192.168.0.1.80 > 192.168.10.3.57206: tcp 5041
18:13:30.015909 IP 192.168.10.3.57369 > 192.168.0.1.80: tcp 0
18:13:30.016042 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 0
18:13:30.016195 IP 192.168.10.3.57369 > 192.168.0.1.80: tcp 0
18:13:30.016388 IP 192.168.10.3.57369 > 192.168.0.1.80: tcp 341
18:13:30.016405 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 0
18:13:30.098483 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 5044
18:13:31.102586 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 5044
18:13:33.346892 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 5044
18:13:34.511978 IP 192.168.10.3.57339 > 192.168.0.1.80: tcp 1
18:13:34.512073 IP 192.168.0.1.80 > 192.168.10.3.57339: tcp 0
18:13:34.512152 IP 192.168.10.3.57339 > 192.168.0.1.80: tcp 0
18:13:37.588787 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 5044
18:13:40.024986 IP 192.168.10.3.57369 > 192.168.0.1.80: tcp 1
18:13:40.025073 IP 192.168.0.1.80 > 192.168.10.3.57369: tcp 0

stephenw10

Was your client still at 192.168.10.2 during that pcap? The connection there from 192.168.10.3 looks good though.

But I would filter the pcap by the IP address of your client to see if traffic is arriving from it.

LaUs3r

@stephenw10
Sorry, I put the wrong IP in the initial post and corrected it meanwhile.
It's 192.168.10.3,.not 192.168.10.2

stephenw10

Hmm, well it looks like it was connected OK then from that pcap. We see traffic both ways. Was it actually failing then?

LaUs3r

@stephenw10 yes, I did not work.

BUT: I GOT IT SOLVED!!! - well that's what I thought

As I was booting the same machine with an Ubuntu Live and successfully connected to pfSense, I figured it needed to have something to do with the Windows 11 installation on that machine. Especially as a fresh Chrome, Edge and Firefox could not connect.

Simple solution in Windows 11:

Settings -> Network & Internet --> Advanced Network Settings --> Reset network

I'd never expected this to work, but it did! - at first

After resetting the network settings and a reboot, I now can access pfSense again

After the reset I tried to configure my network adapter to the previous settings and now I found out what somehow is causing the issue:

As soon as I change the settings of the network adapter for the Jumbo Packet to 9000byte (as I have a 10G network), it's not working anymore.
I assume I somehow have a miss-config of the jumbo packet at the pfSense port or somewhere else

Thx @stephenw10 for your support (so far)

LaUs3r

Finally, it works and it's kinda embarrassing:

I figured that it needed to have something to do with the Jumbo packets
What seems strange to me was that I needed to reboot if I changed the jumbo packet settings in order to have it be applied
Then I checked the driver version. As I was using the Windows Update for drivers as well, I did not expect any surprise.

Well, I was surprised. Driver was from 2020. When I installed the latest version and set the Jumbo packet to 9014, it was instantly applied and I could access the pfSense GUI again

I only can assume that the driver somehow was installed during the Win11 migration few weeks back. I usually access my pfSense via a dedicated admin VM running Linux. Therefore I did not realize that I was not able to access it from my other PC I use "standard" / main tasks.

HAPPY AGAIN

stephenw10

Ah, nice! Yeah in retrospect those 5K byte packets in the pcap should have been a clue. I missed that.