Search results

So, if not activating/using it, best to disable the service then? Any special procedure for that other than disable the service from autostarting?

One additional issue since we made this configuration active is this constant log message: Sep 12 19:22:46 m24 pve-firewall[2376]: status update error: iptables_restore_cmdlist: line 3: CHAIN_DEL failed (Device or resource busy): chain tap141i0-IN pve-firewall should not be active as it's not...

Ok, further to more testing (again) I might have it. I will have to thank for once, ChatGPT for the suggestion... Adding to the chain: -A tap941i0-IN -m state --state ESTABLISHED,RELATED -j ACCEPT Seems to allow outgoing connections correctly. The explanation, which I did not get at the...

This is currently our iptables related logic which coincides I understand with your suggestion and only applies to our first interface which is the public one. We tried various alternatives for in/out dev with no different result: # iptables-save |grep tap941i0-IN :tap941i0-IN - [0:0] -A...

Luckily, I said that! Unfortunately, I was not write and not sure why we thought the issue was solved after deactivating the firewall option on the interface. As we say in Spanish, claimed my victory too soon :oops: It did not make sense in any case, as I get now that the option creates the...

It was yes, and that seemed to be, until further research, the issue. What I still don't get is that I assumed that if pve-firewall was disabled at datacenter/host level all this configurations on the containers and vms did not have any effect, which I was obviously wrong. I also don't...

I found a "glitch" on my setup as per my last comment. For my solution of sending all bridged traffic to a specific interface of a VM to my own chain where I can allow only certain ports and IPs to work I realized I am forced to add a redundant line on that chain to accept outgoing traffic from...

Thanks again. So tap<ID> or veth<ID> should make it enough to just have an array of VMs and CT to apply to. Also, I can see now we could use "tap<id>+" on those rules too as a way to apply to all. But just to understand completely, if we only wanted to limit "external" traffic would we filter...

So, as I've personally had been struggling with this for a very long time, this is an early implementation for a solution to limit and control open ports on a PVE host running CSF as a firewall. This is particularly helpful and intended to allow docker on the VM to manage IPTABLES without the...

Thanks for feedback @shanreich Yes pve-firewall was obviously disabled, and I was trying to add rules to our CSF generated rules to block traffic to that VM interface. I checked: # cat /proc/sys/net/bridge/bridge-nf-call-iptables And it shows disabled (0) so I'm wondering now if that had to...

Still trying this for our specific environment, this is... using CSF firewall at host level and adding rules to follow pve-firewall of blocking traffic to the tap interface of the KVM or container. Still trying to figure out a command/s to identify the corresponding interface to a specific vm...

Thanks. First phrase was just wrongly expressed, sorry, I meant that "rules" are applied at host level which as you explained they are. I also understand now that firewall needs to be activated at data-center+node+vm (+ interface level too) for rules to be created. My concern in our case is the...

The main need to incorporate the pve-firewall is try to limit accesses to a Docker server under a KVM. I'll have to some testing, but I want to understand that pve-firewall will always apply root exclusively at host level by means of blocking the interface itself. Just wondering how it does to...

Thanks. I was guessing it was not the case but it could have well been. Still getting used to ZFS pool space sharing we maintained by mistake default backups pointing to "local" which is /var/lib/vz" and that got too crowded! So, not directly related to the thread subject (I should perhaps...

On a clean new PVE install we are having some repeting issues with failing logins with system users. Journal shows: Aug 12 18:00:00 m24 pvedaemon[279146]: authentication failure; rhost=::ffff:79.XXX.XX.95 user=luison@pam msg=cfs-lock 'authkey' error: got lock request timeout systemctl status...

Thanks. So I understand then that pve-firewalls will create iptables rules. On the host affecting the KVM/CT or inside those? Any documentation on what CHAINs pve-firewall creates? Any commands to add or remove ips from those sets from the command line (ie via cron)?

Hi, we've never used pve-firewall and now trying to consider it for a server. This is an OVH installation so we have a host IP and additional ones assigned to a KVM. I did some testing but none of the rules applied to the KVM itself seemed to work. At the host level they worked but only after a...

So had a try to # proxmox-boot-tool kernel unpin Removed /etc/kernel/next-boot-pin. Removed /etc/kernel/proxmox-boot-pin. But then we noticed that /etc/kernel contained a file named proxmox-boot-manual-kernels with the "5.3.10-1-pve" on it. So we also removed it... and rebooted. A kernel...

Do not think we've ever pinned one but we'll give it a try. In any case I understand being that the case after doing that shouldn't proxmox-boot-tool refresh Produce a different output? Is the "/dev/disk/by-uuid/2C6E-A8ED contains no grub directory - skipping" correct reply of the command?

We've just upgraded a server to PVE8 from Vo7. All went smooth but I am rather uncertain of why the kernel is not being updated. proxmox-boot-tool kernel list Manually selected kernels: 5.3.10-1-pve Automatically selected kernels: 5.15.158-2-pve 6.8.8-4-pve proxmox-boot-tool status...