# These are the iptables rules that I use for my home system.  It
# shows off a number of cool iptables features and shows how to do
# some things which may seem leas clear in iptables than ipchains.

# COOL FEATURES:
#   stateful inspection makes for _FAR_ fewer rules
#   built-in NAT (including masquerading and port-forwarding)
# NON-OBVIOUS THINGS:
#   clean logging

# System this is used for:
#   Router/Firewall on DSL using Masquerading
#   eth0 - internet
#   eth1 - internal network on 192.168.0.0/24
#   forward port 2222 to internal machine's ssh port for "direct" ssh
#           access to my desktop machine

# Everything that I learned about iptables, I got from:
#    1) the docs at http://netfilter.samba.org/unreliable-guides/
#    2) scratching my head a lot and playing with them

# Michael D. Stenner <mstenner@phy.duke.edu>
# 16 August, 2001 - first commented
# 30 July, 2002 - de-scriptified and removed some redundancy

######## Network Address Translation

# edit the nat table
*nat

# set up the policies
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Port-forward [ eth0:2222 -> 192.168.0.3:22 (tcp) ]
-A PREROUTING -i eth0 -p tcp --dport 2222 -j DNAT --to-destination 192.168.0.3:22

# Masquerade out eth0 Note that masquerading is best if your IP
# address can change.  If it's static (or dhcp static), Source NAT
# (SNAT) is recommended.  I go with MASQUERADE anyway just in case.
# It doesn't really hurt anything except potentially a little
# performance, but it leaves me safer if my provider gets stupid.  
-A POSTROUTING -o eth0 -j MASQUERADE

# commit our settings
COMMIT

######################################################################
# Now set up the filtering.  We begin by setting the policies (what 
# happens when no rules match)

# edit the filtering table
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# This creates a new chain that logs and drops everything.  This is
# because in iptables, we can no longer log _and_ drop (or reject, or
# accept) in the same rule.  This is an easy workaround.  You can also
# use this technique to log with different messages for later sorting
# (like with syslog-ng or dulog).

:LDROP - [0:0]

-A LDROP -j LOG --log-prefix "iptables: LDROP " 
-A LDROP -j DROP 

######################################################################
# Set up the INPUT chain

# accept all packets from internal interface, local interface, and ICMP
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT

# accept ssh, upstream dhcp
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p udp --sport 67 --dport 68 -j ACCEPT

# (NOTE: I'm not even sure that the DHCP line needs to be here.  I'm
#     not sure if the reply would be considered "NEW" or not, because
#     the initial contact made by the client may be sent out as a
#     broadcast.  I hope to check this out some time.)

# drop all other incoming connections and screwed-up packets
-A INPUT -i eth0 -m state --state NEW,INVALID -j LDROP

######################################################################
# Now do the FORWARD chain
# note that the use of the FORWARD chain is a bit different from (and
# much more sensible than) its use in ipchains.  See the linked HOWTOs
# for details.

# allow port forwarding for [ eth0 -> 192.168.0.3:22 (tcp) ]
-A FORWARD -i eth0 -p tcp -d 192.168.0.3 --dport 22 -j ACCEPT

# Disallow NEW and INVALID incoming or forwarded packets from eth0.
-A FORWARD -i eth0 -m state --state NEW,INVALID -j LDROP
######################################################################
COMMIT