Reply To: Simple (easy to manage) Firewall / Virtual Server Zeroshell

Forums Network Management ZeroShell Simple (easy to manage) Firewall / Virtual Server Zeroshell Reply To: Simple (easy to manage) Firewall / Virtual Server Zeroshell


First can I just clarify how we can work this – just so I know it’s going to do the job? Perhaps there could be some other good suggestions?

Auto VServer FW Rule Script

GOAL: To create a script which would effectively auto generate corresponding firewall rules from Zero Shell port forwarding Virtual Server rules.

Currently with Zeroshell, firewall rules need to be added separately when each virtual server (NAT) rule is created. Because of this – if a Zero Shell administrator is dealing with a situation where there are 100’s of Virtual Server rules, or a customer that is not confident to generate and manage their own firewall rules – there is a lot of duplicated work to do, plus lots of opportunity for mistakes to cause problems.

Auto generating FW rules would remove a significant amount of work, and thus – this is the goal of this script.

We have split the script in to three phases. SETUP, IMPLEMENTATION and TEST & SET.


1) Setup Script runs from command line (of course GUI would be a bonus)

2) Script looks for a chain called ‘vserver’ if not exist, creates it. Default policy on this chain is ALLOW all.

3) Script creates new rules for INPUT, FORWARD and sets all traffic from ETH0 to be filtered by our new vserver chain.

4) If INPUT & FORWARD have default rule as ACCEPT, these are changed to DENY.

All traffic should now be filtered by the new vserver chain, which we set to ALLOW all – so everything should still work. The firewall is still effectively disabled at this point. Setup is complete.


5) Script then examines all vserver entries and creates firewall rules for them, placing these into the ‘vserver’ chain.

6) After the final vserver generated rule, there needs to be a way to send any traffic that does not match the generated rules someplace else so it can be ‘post processed’ (another chain?) this is also set to default ACCEPT.

7) Now we have all our rules in place, none of them are actually ‘active’ because we have default ‘ACCEPT’ policies set.

User should be able to manually view all firewall rules in the vserver chain, and double check them. Implementation completed.


8) A separate ‘test & set’ script is run which basically changes the default ACCEPT policies for vserver and post process chains to DENY. After 30 secs this script reverts vserver default policies back to ‘ACCEPT’ and presents the user with an option to ‘apply changes’ (permanent) or ‘retest’.

Would it also be possible to turn the script around and automatically create rules for going the other way? So from the vserver to ETH0? In which case would be be talking about generating & populating two chains – vserver_in & vserver_out?

I always thought the ‘RELATED’ filter option was supposed to get around this (as ZS is statefull) but this doesn’t seem to work. If you have an ‘internal’ web server on, and you want an outside web client to connect to it via the ZS ETH0 IP of – you first need to create a rule allowing port 80 from ETH0 to the web server, but you also need to create a rule allowing traffic to pass from the webserver, back to the client.

I thought ‘RELATED’ did away with the need to do this – for some reason, you have to create rules going the other way also.

Anyway – how does this spec look? Reasonable? Possible? Useful!?