Hi,

I'm running Slackware64 14.1 on my LAN server, a little HP Proliant box that acts as local firewall, router, proxy, file server etc.

My firewall is a simple hand-crafted rc.firewall script. Among other things, it contains a line to forward packets:

The rc.ip_forward script is activated accordingly.

I wonder if this is the right place for the forwarding iptables rule. I'm hesitant about putting it somewhere in rc.ip_forward.

How do you folks configure this?

I use same way, create rc.firwall, and invoke it from rc.local, if it execute bit set.

You don't need to invoke it from rc.local. Check out /etc/rc.d/rc.inet2:

My question was: does rc.firewall or rc.ip_forward seem a more appropriate place to put an iptables packet forwarding rule?

1 members found this post helpful.

Thanks for educating me. I didn't even know that rc.ip_forward existed. But I haven't used Slackware as a router for a while.

Whenever I've set up Slackware as a multiple port router I just put everything into rc.firewall. I started this practice a few years ago and the rc.xxxx files have changed some over the years. My rc.firewall scripts were long and of course customized for the router needs at the time. I put all the kernel flag setting (via the /proc system) in the first section of the script where I also set up the variables used by the script.

As you know it's all just scripts, one script running another, so it's just an organizational style issue.

If I was setting up a router today I would try to follow the default Slackware structure as much as possible and put my firewall rules in rc.firewall. I'd let the rc.inet2 script run both rc.firewall and rc.ip_forward as it looks like it does these days.

This way rc.ip_forward could stay unaltered and all the changes that happen over time are confined to the rc.firewall file. If I want to see the state of things with the firewall setup on a box I would find most of the information in the appropriately named "rc.firewall" file.

Regarding the sequence of running the scripts, note the sentence in your quote about possibly changing the order in which these two scripts execute...

As I mentioned, I always enabled the forwarding first. I note this in case you end up using the default rc.inet2 method and have trouble. Current documentation on netfilter will probably describe the sequence issues.

HTH

EDIT: Organizationally, notice that the rc.ip_forward file doesn't use the "iptables" command. Only kernel flags are set.

It is probably better to keep all of your "iptables" commands in the same file so you can more easily spot sequencing issues or other conflicting command problems. (of course that could still be in the rc.ip_forward file)

The naming of the file "rc.ip_forward" suggests it's purpose. To put commands other than "forwarding" commands in the file makes it less clean. You could argue that your iptables command is about forwarding, but if you add additional iptables commands later they should be kept together and those iptables commands may not be about packet forwarding.

Whew...a lot of typing over a single iptables command.

EDIT2: allend and 55020 make better arguments in much less space.

1 members found this post helpful.

My take on this is that I do not want forwarding without iptables rules, so I prefer to to activate packet forwarding within the iptables script (rc.firewall).

rc.firewall is what GOD would use [citation needed]. It's like rc.local, it is the designated container for your iptables commands.

rc.ip_forward isn't really intended for local commands. You *can* add them there, but you will have extra work to merge your old copy into Pat's new copy every time network-scripts is upgraded.

When I had my firewall/router/file server couple years ago, using standalone tplink router now, I got rc.firewall from Easy Firewall Generator, I left that alone and made rule changes/additions in rc.local as that's last thing rc.M does and all the network stuff seemed to be done at that point.

I see in /etc/rc.d/rc.inet2 that rc.ip_forward is read *after* rc.firewall:

I've never used rc.ip_forward. I use to include the command:

in the rc.firewall itself *before* iptables related to forwarding. For example:

I ignore if adding the rules *after* could mean a problem (and I'd like to know it).

It's not a problem, eloi. However, for a fraction of a second you would have forwarding enabled without any firewalling rules. Depending on what those rules set, it could be considered a small security hole while booting the system. It's better if you enable the firewalling rules before allowing packet forwarding in the kernel.

1 members found this post helpful.

OK. Thanks!

Anyway my script has previous rules (starting with a drop policy).