My DietPi install in a Proxmox VM became unreachable. netstat from my laptop showed no ports open. I connected via console in Proxmox, and everything looked fine internally, including various services such as dropbear and lighttpd listening to their ports. Rebooting did not help. There was no firewall running that I can find.
I deleted the VM and created a new DietPi install. This worked fine for about 24 hours, then exhibited the same behavior: it suddenly became unreachable, but everything looks fine when connected via console. I cloned the VM and launched a new identical copy of the DietPi install. This copy again works fine.
I am experiencing a similar issue with a latest version instance in Hyper-V. After 24 hours of uptime the VM loses its DHCP-assigned address via virtual network interface but can re-negotiate properly from the console via dietpi-config or system restarts. I believe the issue began following the update to the latest version of DietPi.
From our point we don’t have done anything on this layer. There might be a coincidence with some packages that has been upgraded in parallel. If you have a backup, it might be possible to restore on a different VM. This way it could be checked which packages are available for update.
@Joulinar: I suspected proxmox too, but the firewall is turned off there and I can’t find any indication that it’s causing the problem, but it’s still a suspect
@helloelan: My issue is different. I’m using a static IP. This is all about ports being filtered
Some updates:
Running nmap from an external machine shows the three ports that should be open as “filtered”, while ports that should be closed are properly shown as “closed”. Again, suggesting that there is something like a firewall running. But why would it turn on spontaneously?
I checked again just now, and the original DietPi has again started to respond. I had restarted it earlier and it was still blocked at the time, but otherwise I haven’t done anything to it the instance. The clone is also still running well. I’m going to keep the output of journalctl -f on the screen so I can see if anything happens when/if it goes out again.
Nope, I don’t have any firewalls running. I’ve checked on both the VMs and on proxmox.
I now have 3 VMs set up, two running identical instances of DietPi with only Pi-hole/Unbound and a third running only Home Assistant. At the moment, one of the Pi-holes is ok, while the second Pi-hole and the HA VMs are both blocked. Interestingly, if I check from the Proxmox host itself, the ports are not blocked.
That makes me think the issue is external to the DietPis, but it was still worth asking here.
Port scan from an external machine:
> nmap -Pn 192.168.0.8-10 -p 22,23,25,80,8123
Starting Nmap 7.93 ( https://nmap.org ) at 2022-09-08 14:02 PDT
Nmap scan report for 192.168.0.8
Host is up.
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
25/tcp filtered smtp
80/tcp filtered http
8123/tcp filtered polipo
Nmap scan report for 192.168.0.9
Host is up (0.0037s latency).
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
25/tcp filtered smtp
80/tcp open http
8123/tcp filtered polipo
Nmap scan report for pi.hole (192.168.0.10)
Host is up (0.0042s latency).
PORT STATE SERVICE
22/tcp open ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp open http
8123/tcp closed polipo
Nmap done: 3 IP addresses (3 hosts up) scanned in 1.45 seconds
Port scan from the Proxmox host:
> nmap -Pn 192.168.0.8-10 -p 22,23,25,80,8123
Starting Nmap 7.80 ( https://nmap.org ) at 2022-09-08 14:04 PDT
Nmap scan report for 192.168.0.8
Host is up (0.00083s latency).
PORT STATE SERVICE
22/tcp open ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp closed http
8123/tcp open polipo
Nmap scan report for 192.168.0.9
Host is up (0.0010s latency).
PORT STATE SERVICE
22/tcp open ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp open http
8123/tcp closed polipo
Nmap scan report for 192.168.0.10
Host is up (0.00086s latency).
PORT STATE SERVICE
22/tcp open ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp open http
8123/tcp closed polipo
Nmap done: 3 IP addresses (3 hosts up) scanned in 0.12 seconds
are there any special network components in between? Some managed switched or other stuff that would have the possibility to block access. I had something similar with a router that I misused as LAN switch and suddenly it starts blocking my PiHole. but just on its current IP. As soon as I changed static IP to something else, PiHole become reachable again.
Hi @free_play, could we check your network settings in the hardware tab of the Proxmox VM?
I am running several DietPi VMs and have no problems since months.
I am using the virtio network card (instead of Intel E1000 or others), VirtIO SCSI (instead of IDE) and the q35 machine type (instead of i440fx).
No special components. Everything was passing through my home wifi router (Netgear Orbi), but over the weekend I finally had the chance to change up my LAN setup – now the Proxmox box is the gateway between my LAN and WAN, and the wifi router has been demoted to an access point. This will give me better control and insight into what’s happening on my LAN.
CD Drive: You have an additional CD drive: Should not make any difference
Hard disk: You have zfs file system instead of lvm: Should not make any difference
Network: You have the firewall disabled: Could make a difference. To change this:
Shutdown your machine
Doubleklick on the line “Network Device” (on the right side)
Activate the firewall
Restart the system
The next thing could be your proxmox host. Which hardware do you use for this?
An option could be to search in the system log of Proxmox for errors. Seems like a search for a needle in the haystack.
I guess OP already checked communication between Proxmox host and VM. As I understood this was working. Issue seems to be between Proxmox host and network and not the VM. Feel free to correct me
@StephanStS The firewall had been on originally (though unconfigured, with no rules), but I turned it off in case that’s where communication was being blocked.
I have reconfigured the networking topology since having my original issues (an OPNsense VM is now the gateway device) and the problems haven’t recurred. The problem is unsolved, but hasn’t recurred since then. So I’ll “close” this ticket for now.