Incorrect IPTables default rules file

I'm not fully certain if this applies to Virtualmin, or Webmin, or possibly to the VMin installation script.

But in a fresh VMin installation with current version, where I just started fiddling a bit with IPTables, I think an incorrect default config was created. My assumption is that it was done by VMin, since there exist rules for ports 10000, 20000, imap, pop3 etc.

The problem as I understand it: In /etc/iptables.up.rules, in the "filter" section, the following lines are missing:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

Instead, the file generated starts like this:

# Generated by webmin
*filter
-A INPUT -p udp -m udp --dport domain -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
...

The missing lines are, as far as I see it, required so that the Webmin module recognizes those default chains, and displays the "Set default action to:" buttons. Without those lines, the INPUT rules do not appear at all in Webmin, as if the "filter" table was completely empty and did not even have default policies.

When I manually "add" a chain named INPUT, the line in the config file reads :INPUT - [0:0], causing the "Set default action to:" button to be missing.

Status: 
Closed (fixed)

Comments

For comparison, after issuing the "Reset firewall / Allow all traffic" command, /etc/iptables.up.rules looks like this: (The 'em' tags are incorrectly interpreted asterisk characters.)

# Generated by iptables-save v1.4.4 on Mon Oct 25 19:02:56 2010
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Mon Oct 25 19:02:56 2010
# Generated by iptables-save v1.4.4 on Mon Oct 25 19:02:56 2010
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Mon Oct 25 19:02:56 2010
# Generated by iptables-save v1.4.4 on Mon Oct 25 19:02:56 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Mon Oct 25 19:02:56 2010

Ok, I see the issue .. the installer doesn't handle the case where no firewall rules exist at all too well.

I will fix this in the next version of the install script that we release. Till then, resetting the firewall is a good solution.

Yup, sure thing. I wasn't having trouble with the firewall either (not using one cause my servers are virtual machines behind a virtual router :) ), I just noticed that incorrect behavior when I did some tests on my experimental VM.

Automatically closed -- issue fixed for 2 weeks with no activity.