Proxmox VM connectivity issue (SOLVED)

[AlphaObeisance]

Last night I was dinking around on the home lab (Proxmox VE 8.2.7 x86_64) and noticed that spite having thought I'd enabled ufw it still showed as inactive. I went ahead and enabled it and went to bed.

I wake up this AM to find that all of my VM's have no internet access.

I ran ufw verbose which yielded

To                         Action      From
--                         ------      ----
8006                       ALLOW       Anywhere            
22/tcp                     ALLOW       Anywhere            
80                         ALLOW       Anywhere            
443                        ALLOW       Anywhere            
67/udp on vmbr0            ALLOW       Anywhere            
53/udp on vmbr0            ALLOW       Anywhere            
8006 (v6)                  ALLOW       Anywhere (v6)       
22/tcp (v6)                ALLOW       Anywhere (v6)       
80 (v6)                    ALLOW       Anywhere (v6)       
443 (v6)                   ALLOW       Anywhere (v6)       
67/udp (v6) on vmbr0       ALLOW       Anywhere (v6)       
53/udp (v6) on vmbr0       ALLOW       Anywhere (v6)       

68/udp                     ALLOW OUT   Anywhere on eno1    
68/udp (v6)                ALLOW OUT   Anywhere (v6) on eno1

so I permitted outgoing traffic. But to no avail.

The primary bridge is the dfault vmbr0 and all VM's operate off that same bridge (never been an issue).

Quite literally the only thing I recall doing was enabling ufw to active on startup and port forwarded. I'm at a loss as to what the issue is (networking is my Achilles heel).

The proxmox webui was unavailable until I forwarded 8006 ofc, but after that it works fine. So the hypervisor itself is getting internet no problem. Confirmed by pinging archlinux.org from Proxmox root to 100% success.

I've also ensured forwarding is enabled.

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Might anyone have any suggestions on how I might begin resolving this one?

EDIT: edited /etc/default/ufw
DEFAULT_OUTPUT_POLICY="DROP" // changed DROP to ACCEPT resolved issue.

 

[f33dm3bits]

The proxmox webui was unavailable until I forwarded 8006 ofc, but after that it works fine.

You mean opened the port in ufw or forwarded in ufw, looks more like opened from looking at your "ufw status" output.

One you should keep in mind is that Proxmox has it's on firewall service running, which is "pve-firewall.service". It could have interfered with a second firewall.service if you installed and enabled ufw yourself and I would think the latter because it isn't installed on my Proxmox system.

Also about this.

I've also ensured forwarding is enabled.

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

I don't have this enabled and everything just works without it, together with the default Proxmox "pve-firewall.service". So if anything broke after you enabled ufw, I would think the two firewall services could have been in each others way.

 

[AlphaObeisance]

You mean opened the port in ufw or forwarded in ufw, looks more like opened from looking at your "ufw status" output.

One you should keep in mind is that Proxmox has it's on firewall service running, which is "pve-firewall.service". It could have interfered with a second firewall.service if you installed and enabled ufw yourself and I would think the latter because it isn't installed on my Proxmox system.

Also about this.

I don't have this enabled and everything just works without it, together with the default Proxmox "pve-firewall.service". So if anything broke after you enabled ufw, I would think the two firewall services could have been in each others way.

I should have known this idk wth I was thinking.

I did actually disable ufw entirely before I got to diving in to see if ufw was the issue but the issue persisted spite having stopped disabled the ufw service. I wonder if having installed and enabled it bricked the proxmox firewall if that's the case?

Now I"m not sure what to do lol. Was all proud of myself for figuring this out but now that I have to take the proxmox firewall into consideration (lets just pretend I'm not a total dummy sometimes), I'm curious if I should leave it alone, or if I should wipe ufw from the system and figure out what to do from there 0_o.

EDIT: Oh for cryin out loud. Maybe I should just stop working on crap before I get my coffee down. I just ran
sudo ufw disable
sudo systemctl disable --now ufw

and it all seems fine. Idk what the heck I was thinking. I might end up DM'ing you about this, bit of a funny story behind it considering you know some of the context about my current situation lol.

All is well. Maybe if I'm lucky a moderator will delete this for me to spare me the eternal shame lol. Or leave it as an example that we all make dumb mistakes sometimes lol.

 

[AlphaObeisance]

So given the level of stupidity I felt this AM after reading f33dom3bits response I did some homework (over coffee, I promise lol). Figured I'd share for those getting into Proxmox themselves.

The following as a summarized breakdown of Proxmox's firewall options.

1. Firewall: Yes
Explanation: This enables the firewall on Proxmox, allowing you to manage rules for incoming and outgoing traffic.

Recommended Setting: It’s good to keep the firewall enabled to protect your environment, even in a home lab.

2. SMURFS Filter: Yes
Explanation: This setting mitigates against Smurf attacks, a type of DDoS attack where ICMP packets are used to flood a target.

Recommended Setting: Keeping this enabled helps protect against certain types of network attacks.

3. TCP Flags Filter: No
Explanation: This setting would allow filtering based on TCP flags, helping to identify and block abnormal TCP traffic patterns.

Recommended Setting: (consider enabling). In a home lab, you might not face high traffic, but enabling this can help detect malformed packets if you are testing various network configurations.

4. NDP: Yes
Explanation: NDP (Neighbor Discovery Protocol) is used in IPv6 networks to discover other network nodes. Enabling this helps manage IPv6 traffic.

Recommended Setting: (if you are using IPv6). If your home lab doesn't use IPv6, you can safely set this to No.

5. nf_conntrack_max: Default
Explanation: This sets the maximum number of concurrent connections that the connection tracking system can handle.

Recommended Setting: You can leave this as Default, but if you anticipate high connection rates or testing load, consider increasing this value to accommodate more simultaneous connections.

6. nf_conntrack_tcp_timeout_established: Default
Explanation: This controls how long an established TCP connection can stay in the connection tracking table.

Recommended Setting: Default is usually fine for a home lab. Adjust only if you have specific use cases that require a different timeout.

7. log_level_in: nolog
Explanation: This controls the logging level for incoming connections.

Recommended Setting: For a home lab, you might want to set this to low or medium to monitor incoming traffic without overwhelming logs.

8. log_level_out: nolog
Explanation: This controls the logging level for outgoing connections.

Recommended Setting: Similar to incoming, consider setting this to low or medium for outgoing traffic to gain insights without excessive logging.

9. tcp_flags_log_level: nolog
Explanation: Controls the logging of TCP flags. Useful for debugging.

Recommended Setting: nolog is fine, but you could set it to low if you're doing testing that involves TCP behavior.

10. smurf_log_level: nolog
Explanation: This controls the logging of smurf-related packets.

Recommended Setting: nolog is fine, but consider enabling logging if you're testing network security scenarios involving DDoS attacks.