[Wolves] IP Tables

James Turner james at turnersoft.co.uk
Tue Dec 20 19:42:43 GMT 2005

On Tuesday 20 Dec 2005 18:49, Adam Sweet wrote:
> --- David Goodwin <david at codepoets.co.uk> wrote:
> > Adam Sweet wrote:
> > > --- David Goodwin <dg at clocksoft.com> wrote:
> > >>>-A PREROUTING -p tcp -i eth0 --sport 443 -j DNAT
> > >>
> > >>--to
> > >>
> > >>> 443
> >
> > Looking at it again, I suspect you need --sport to
> > be --dport.
> Ahh yeah, I've been fiddling. I'm not sure if that has
> always been like that but I now have:
> *nat
> :OUTPUT ACCEPT [105:6517]
> -A PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to
> and I get a connection refused error which I've had
> before. But at least you are reassuring me that I'm
> not completely wrong, just crap at paying attention to
> what I'm typing.
> Interestingly:
> [root at machinex sysconfig]# /etc/init.d/iptables status
> Table: nat
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> DNAT       tcp  --  anywhere             anywhere
>      tcp dpt:https to:
> target     prot opt source               destination
> MASQUERADE  all  --      anywhere
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> but:
> [root at machinex sysconfig]# iptables --list
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> Thats weird, no? Getting closer? IP tables, as per the
> iptables script in /etc/init.d/iptables is running.

The reason why you get different output is that there are several different 
"tables", each containing rules.

The first one listed above is the NAT table (command: iptables -L -v -t nat), 
the second is the filter table, which is the default (compare: iptables -L -v 
-t filter).

The way I like to do it (masochistic or what!) is to write a BASH script that 
clears and configures iptables from scratch, then when everything's OK do:

/sbin/service/iptables save

which will save the setup ready for next boot.

As for the setup you are after, try something like this:

DISCLAIMER: Written in a rush, so much debugging probably needed before it 

1. Set up each interface on the firewall machine with appropriate IP 
addresses, netmasks, etc, for the network they are connected to. Once it's 
done right you should be able to access both the Internet and the local 
network from this machine.

2. Set policy to refuse any packets (temporary until firewall configured):

iptables -P INPUT DROP

3. Enable routing

echo 1 > /proc/sys/net/ipv4/ip_forward

(Eventually put this in /etc/rc.d/rc.local, to execute once the rest of the 
startup scripts have completed)

4. Add IP masquerading

iptables -t nat -A POSTROUTING -o <firewall's internet interface> -j SNAT --to 
<firewall's public ip address>

where the interface and IP address match the externally facing interface on 
the firewall, for example:

<firewall's internet interface>  =   eth1
<firewall's public ip address>   =

5. Configure accepting of packets that are to be routed (not sure how many of 
these are needed - experimentation recommended) and non syn packets to be 
accepted from anywhere. (although better to use IP tables connection 
tracking... instructions to be upgraded I guess)

iptables -A INPUT -s <local net> -d <firewall's internal ip address> -p all -i 
<firewall's internal interface> -j ACCEPT

iptables -A INPUT -p tcp ! --syn -j ACCEPT


<local net>                        =
<firewall's internal interface>    = eth0
<firewall's internal ip address>   =

6. Save the settings for the next reboot using:

/sbin/service iptables save

7. Enable the "iptables" service using your favourite config tool. (e.g. 
system-config-services for the timid, ln -s for the brave and foolhardy!) 
Also, add "echo 1 > /proc/sys/net/ipv4/ip_forward" to the end 
of /etc/rc.d/rc.local.

8. Test using:

/sbin/service iptables start

9. Complain bitterly at the LUG meeting tomorrow when it doesn't work. :)

Hopefully people are still up for a possible iptables talk in the new year?... 
will try not to be too academic/boring. :)

Another approach, possibly less complicated, would be to deploy a SQUID (or 
similar) proxy and use that. You get caching too (with HTTP, anyway).



More information about the Wolves mailing list