Hi Alberto, hi Jamie, Am 17.02.20 um 18:06 schrieb Alberto Molina Coballes: > > These rules were not generated by ufw. The current released version of > ufw does not do any management of the nat table. Furthermore, > iptables-restore rules in /etc/ufw/*rules do not contain any '-F's. >
I made these rules myself and had to add the -F's because ufw does not flush the nat table on reload and I would otherwise end up with duplicate nat rules. > The man page does *not* document use of -F in these files and instead > has examples like: > > *nat > :POSTROUTING ACCEPT [0:0] > -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE > COMMIT > > So I suspect what happened is the reporter used this mechanism to > customize the firewall and accidentally added the second, errant -F. > [/quote] > After some test, it seems that the problem is related to the flush of > the rules after adding some of them (do you really want to do that?), > because the next ruleset works well: > The second -F is for the POSTROUTING rules. The difference is here: *nat -F PREROUTING -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194 -F POSTROUTING -A POSTROUTING -o eth0 -p tcp --sport 222 -j SNAT --to-source 10.10.10.10 COMMIT results in a crash. *nat -F PREROUTING -F POSTROUTING -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194 -A POSTROUTING -o eth0 -p tcp --sport 222 -j SNAT --to-source 10.10.10.10 COMMIT does not crash. > Because the default iptables-restore behaviour is to flush (delete) > all previous contents of the respective tables. If I remove the -F's, every 'ufw reload' will add another set of the POSTROUTING and PREROUTING rules. > > I think you can workaround the bug rewriting your rules with special > care in the inclusion of '-F' rules. The workaround is to have both -F rules at the beginning. But I can't omit them. Christoph
signature.asc
Description: OpenPGP digital signature