Proxmox VE 8 with Firewall in Routed Configuration. Netfilter POSTROUTING SNAT not working

[Michi]

Hi,
since switching to Proxmox VE 8 Postrouting SNAT (Unfortunately I must use NAT) in combination with the Proxmox Firewall is not working anymore even with conntrack zones enabled.
In Proxmox VE 7 it worked after adding

post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1 
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

to the /etc/network/interfaces.


This is how my /etc/network/interfaces looks like

auto eno1 
iface eno1 inet static 
        address <Main public IP>/26 
        gateway <Gateway IP> 
 
 
 
 
 
 
auto vmbr0 
iface vmbr0 inet static 
        address <Main public IP>/32 
        bridge-ports none 
        bridge-stp off 
        bridge-fd 0 
        #fix for SNAT and VE Firewall 
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1 
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 
 
 
        #SNAT for Backup 
        post-up iptables -t nat -A POSTROUTING -s <internel IP Backup>/32 -o eno1 -j SNAT --to-source <Main public IP> 
        post-down iptabels -t nat -D  POSTROUTING -s <internel IP Backup>/32 -o eno1 -j SNAT --to-source <Main public IP>

Any feedback is much appreciated.

Best regards

 

[spirit]

does it work if you boot on old kernel 5.15 ? (maybe something have changed in netfilter, not sure abou that)

 

[Michi]

Proxmox 7 with kernel 5.15.30 - working
Proxmox 8 on Bookworm with kernel 6.2.16-> Not working

 

[kemeris]

Same problem here after upgrade to Proxmox 8. I would appreciate any help.

 

[enlar]

This is working in Proxmox 8.2 with kernel 6.8.8-4 for us.

 

[lethargos]

This isn't working in my case on 8.2.7 with kernel version 6.8.12-1.
I've just come across this thread after trying to understand what's happening. It's clear that the host simply ignores the SNAT rule when the VM firewall (interface + VM level) and forwards the packet without translation the source IP address, I can clearly see the difference in tcpdump.

Any ideas why this is happening or how it can be solved?

 

[lethargos]

I realised that this rule:
-A PREROUTING -i fwbr+ -j CT --zone 1
was missing from the raw chain. After adding it, it worked. The packets need a separate conntrack zone in order for SNAT to work, otherwise they're considered "known" (so not new), and will not travel through the nat (POSTROUTING) table anymore.

Later edit: I've just realised this isn't particularly helpful, given that you're mentioning this from the very beginning

 

[pmickael]

I face the same problem !

By default there is rules in iptables on iptables -L FORWARD -v -n --line-numbers

You should probably see that package a DROP like this :

15     513 42597 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 1/sec burst 5 LOG flags 0 level 4 prefix "DROP UNMATCHED PASS-unknown:"

And to fix just do (adapt to you configuration) :

iptables -I FORWARD 1 -i vmbr9 -o vmbr0 -s 10.10.10.0/24 -j ACCEPT
iptables -I FORWARD 2 -i vmbr0 -o vmbr9 -d 10.10.10.0/24 -j ACCEPT

 

[lethargos]

I don't think that's good advice. The firewall should take care of the FORWARD rules, and as a permanent solution I don't think you should do that. It would be a good test just for debugging purposes to see if it works. Otherwise you're interefering with the logic of the firewall. And if the firewall doesn't work as it's supposed to (of which I wouldn't be surprised), then that should be highlighted as such and brought to the attention of the developers.

If you look at the second rule in the PVEFW-FORWARD chain, which is referenced in the FORWARD chain, you'll see:

iptables -vnL PVEFW-FORWARD --line
Chain PVEFW-FORWARD (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1    13664  710K DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
2    1509M 1488G ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

The second rule takes care of the conntrack, so there's no need to interfere with that by accepting and outbound and inbound traffic regardless of the conntrack.