Proxmox Host and VM Cannot Connect to a Device on My LAN

[henryjr]

I’m facing a strange networking issue with my Proxmox setup:

What Works:
• On macOS (on the same network), the following operations are successful:
• ping 192.168.86.150 works
• curl http://192.168.86.150 successfully retrieves the webpage
• netcat works nc -zv 192.168.86.150 4025 connects

What Doesn’t Work:
• On my Proxmox host (192.168.86.47):
• ping 192.168.86.150 works
• curl http://192.168.86.150 hangs with no response
• netcat fails: nc -zv 192.168.86.150 4025 hangs

• On a VM running in Proxmox (bridged via vmbr0):
• Behavior is identical to the host: ping works, but curl and netcat fail.

What I’ve Tried:
1. Verified the Proxmox host’s and VM’s network configurations:
• Host IP: 192.168.86.47/24 via vmbr0 (bridged to enx803f5d096607).
• VM uses the same bridge (vmbr0) and is in the same subnet (192.168.86.0/24).

2. Edited /etc/cloud/cloud.cfg to prevent cloud-init from managing /etc/hosts:
• Added: manage_etc_hosts: false.
• Restarted cloud-init: sudo systemctl restart cloud-init.

3. Edited /etc/hosts to add:
192.168.86.150 envisalink.lan
• This allowed me to resolve envisalink.lan via ping but didn’t fix curl or netcat.

4. Confirmed ARP resolution on the Proxmox host (REACHABLE state for 192.168.86.150).

5. Ran tcpdump on vmbr0:
• Outgoing SYN packets to 192.168.86.150:4025 are sent, but no response is received:

16:10:22.614325 IP pve.lan.42758 > envisalink.lan.4025: Flags [S], seq 419231085, win 64240, options [mss 1460,sackOK,TS val 1664074109 ecr 0,nop,wscale 7], length 0

• This suggests the target device doesn’t respond to the Proxmox host.

6. Tested curl -v http://envisalink.lan:
• Resolves to 192.168.86.150 but hangs:

          * Host envisalink.lan:80 was resolved.
          * IPv6: (none)
          * IPv4: 192.168.86.150
          * Trying 192.168.86.150:80...

Setup Details

• Proxmox is running on a MacBook Air using a USB-to-Ethernet dongle.
• The Proxmox setup allows Wi-Fi as a backup internet option (currently disabled for testing).

/etc/network/interfaces​

auto lo
iface lo inet loopback

# WiFi interface for bridge
# allow-hotplug wlp3s0
# iface wlp3s0 inet static
#    metric 600
#    post-up ip route add default via 192.168.86.1 dev wlp3s0 metric 600

# Ethernet interface
allow-hotplug enx803f5d096607

# Bridge for Proxmox
allow-hotplug vmbr0
auto vmbr0
iface vmbr0 inet static
    address 192.168.86.47/24
    gateway 192.168.86.1
    bridge_ports enx803f5d096607
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
    bridge_waitport 0
    # Enable IPv4 forwarding for VMs
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward

source /etc/network/interfaces.d/*

/etc/NetworkManager/NetworkManager.conf:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

[device]
wifi.scan-rand-mac-address=no

[connection]
autoconnect-retries-default=0

[keyfile]
unmanaged-devices=interface-name:vmbr0;interface-name:enx803f5d096607

Device Notes:
• The target device (EnvisaLink DUO, 192.168.86.150) is a TCP-IP/LTE-based interface for DSC PowerSeries and Honeywell Vista panels. It allows viewing and controlling an alarm panel via a browser or smartphone.
• The device responds to all traffic from macOS (including curl and netcat), so it doesn’t seem to be an issue with the device itself.
• There are no known firewalls or access restrictions on the target.

Questions:
1. Why would the Proxmox host and its VMs fail to establish connections beyond ping when macOS works flawlessly on the same subnet?
2. Could the USB-to-Ethernet dongle or the bridged setup be causing this issue?
3. Are there additional diagnostics or settings I might have missed?


Thank you in advance for any insights!

 

[henryjr]

Resolved the issue: traffic was being filtered even though no firewall was present.

Initial Nmap scan result:

nmap -p 80 192.168.86.150
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-06 19:54 PST
Nmap scan report for 192.168.86.150
Host is up (0.00061s latency).

PORT   STATE    SERVICE
80/tcp filtered http
MAC Address: 00:XX:XX:XX:XX:XX (Envisacor Technologies)

Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

Discovered that the USB dongle had RX/TX checksumming enabled, which caused the issue. I disabled it using the following command:

sudo ethtool -K enx803f5d096607 rx off tx off


After disabling checksumming, the Nmap scan confirmed traffic was no longer being filtered:

nmap -p 80 192.168.86.150
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-07 10:45 PST
Nmap scan report for 192.168.86.150
Host is up (0.00062s latency).

PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:XX:XX:XX:XX:XX (Envisacor Technologies)

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds