Web GUI not accessible in 7.1

[sammy]

Hi, I'm new to proxmox and have just installed version 7.1. When accessing the web gui, the request did go through to my proxmox machine, but it didn't show up in the pveproxy access logs. Now as I wanted to create a thread I wanted ssh access so I could copy-paste a bunch of stuff and copied the ssh key that is present after the installation to my local machine. After ssh-ing into proxmox the web gui is now suddenly accessibly? Can somebody elaborate as to why this is happening? Surely, the web gui doesn't need the ssh key present. Does ssh-ing into proxmox whitelist the IP I want to access the web gui from?

EDIT: just tried with another machine (notebook) and now I cannot ssh/access web gui from either machine...

EDIT2: the moment I try to access the web interface on my notebook (not ssh'd into proxmox) the ssh connection on my main machine breaks and the web interface is also not accessible anymore. After a few minutes I can again ssh from my main machine and access the web ui. No clue how to debug this.

EDIT3: now this is very weird. When I open an sftp session from proxmox to my main machine

sftp sammy@my-pc-ip

ssh and the web ui are working on this machine. The moment I close the sftp session and try my to access the UI from my notebook it blocks ssh and the web UI again.

 

[mira]

Perhaps a duplicate IP or MAC address in your network? Probably on your PVE and your main machine?

 

[sammy]

Perhaps a duplicate IP or MAC address in your network? Probably on your PVE and your main machine?

No not to my knowlegde. I keep DHCP addresses to 192.168.1.100-192.168.1.255 and my proxmox machine has 192.168.1.90, which no other machine uses as a static IP.

EDIT: when ssh and UI are not working a short ping from my machine to proxmox seems to "fix" the problem

 

[sammy]

This reddit post suggests also that there is an error in the ARP table, but I looked at it in the pfSense web UI and it looked exactly the same before and after I pinged the server:

 

[mira]

Well, that's the most common issue when a simple `ping` can fix this temporarily.
Maybe something else in the network?

You could try to trace the traffic with `tcpdump` to see if anything interferes.

 

[sammy]

Apperently the packets still go through. Here's the output of

tcpdump -i vmbr0 port 8006

when the web UI is not working:

11:47:43.060004 IP 192.168.1.122.47842 > 192.168.1.20.8006: Flags [S], seq 1334214748, win 64240, options [mss 1460,sackOK,TS val 2141245646 ecr 0,nop,wscale 7], length 0
11:47:43.060137 IP 192.168.1.20.8006 > 192.168.1.122.47842: Flags [S.], seq 3135261566, ack 1334214749, win 65160, options [mss 1460,sackOK,TS val 3651874356 ecr 2141245646,nop,wscale 7], length 0
11:47:43.308351 IP 192.168.1.122.47844 > 192.168.1.20.8006: Flags [S], seq 1220713825, win 64240, options [mss 1460,sackOK,TS val 2141245897 ecr 0,nop,wscale 7], length 0
11:47:43.308375 IP 192.168.1.20.8006 > 192.168.1.122.47844: Flags [S.], seq 1288613813, ack 1220713826, win 65160, options [mss 1460,sackOK,TS val 3651874604 ecr 2141245897,nop,wscale 7], length 0
11:47:44.075905 IP 192.168.1.122.47842 > 192.168.1.20.8006: Flags [S], seq 1334214748, win 64240, options [mss 1460,sackOK,TS val 2141246662 ecr 0,nop,wscale 7], length 0
11:47:44.075932 IP 192.168.1.20.8006 > 192.168.1.122.47842: Flags [S.], seq 3135261566, ack 1334214749, win 65160, options [mss 1460,sackOK,TS val 3651875372 ecr 2141245646,nop,wscale 7], length 0

where 192.168.1.20 is my proxmox box and 192.168.1.122 is my pc.

EDIT: I trimmed the tcpdump for only the first 3 connection establishing phases. Apparently my client does not send back the ACK to complete the connection establishing phase of TCP. After a short ping, it does and data is transferred:

12:08:29.245928 IP 192.168.1.122.47850 > 192.168.1.20.8006: Flags [S], seq 1977059420, win 64240, options [mss 1460,sackOK,TS val 2142491801 ecr 0,nop,wscale 7], length 0
12:08:29.245961 IP 192.168.1.20.8006 > 192.168.1.122.47850: Flags [S.], seq 3577059704, ack 1977059421, win 65160, options [mss 1460,sackOK,TS val 3653120542 ecr 2142491801,nop,wscale 7], length 0
12:08:29.246920 IP 192.168.1.122.47850 > 192.168.1.20.8006: Flags [.], ack 1, win 502, options [nop,nop,TS val 2142491807 ecr 3653120542], length 0
12:08:29.248501 IP 192.168.1.122.47850 > 192.168.1.20.8006: Flags [P.], seq 1:606, ack 1, win 502, options [nop,nop,TS val 2142491808 ecr 3653120542], length 605
12:08:29.248513 IP 192.168.1.20.8006 > 192.168.1.122.47850: Flags [.], ack 606, win 505, options [nop,nop,TS val 3653120545 ecr 2142491808], length 0
12:08:29.249207 IP 192.168.1.20.8006 > 192.168.1.122.47850: Flags [.], seq 1:1449, ack 606, win 505, options [nop,nop,TS val 3653120545 ecr 2142491808], length 1448
12:08:29.249211 IP 192.168.1.20.8006 > 192.168.1.122.47850: Flags [P.], seq 1449:1769, ack 606, win 505, options [nop,nop,TS val 3653120545 ecr 2142491808], length 320

EDIT2: So I ran tcpdump on my local machine as well (needless to say the output is very noisy) and the client apparently never receives the SYN-ACK packet, which I have no clue how to further debug this.