Re: [LARTC] IP Tables on a bridge

[Grant Taylor <gtaylor@riverviewtech.net>]

ICI Support wrote:
> I have a bridge.  On one side of the bridge is that fancy thing called the
> Internet.  On the other side is my LAN.  The bridge is the obvious
> demarcation line and a good place to put a firewall.

*nod*

> Now, I have all my iptables stuff planned out, EXCEPT for nat.
> 
> The usual way to do NAT:
> 
> iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE
> 
> iptables -A FORWARD -j ACCEPT
> 
> Now, the problem I have is that my LAN is mixed NAT'd addresses and routable
> IPs.  I have a host of FORWARD rules to determine which packets get sent
> onto which servers (routable IPs).  My worry is that if I put in the
> "iptables -A FORWARD -j ACCEPT" it'll defeat the whole purpose of those
> entries.

Put the (new) rules in question below the other rules that you have in place now.

> My question is:  How do I set up a FORWARD for JUST the NATed packets
> without touching the non-NATed packets?   Would a -d to my internal network
> ($INTERNAL_NET is set to 192.168.10.0/24) do it?
> 
> IE would this work:
> 
> iptables -A POSTROUTING -t nat -s $INTERNAL_NET -j MASQUERADE
> 
> iptables -A FORWARD -d $INTERNAL_NET -j ACCEPT

Yes this should work.

> Also, if I post up my iptables entries/script, can someone help me proof
> them for problems?

Sure (but others have and I have not looked at it yet).

I question why you don't do this as a Bridging Router?  I know that you have said (in another email) that you have concerns over using a BRouter.  (I think) This would be quite easy to do as a BRouter.  To do so you would bridge your external and internal interfaces together and set up a rule such that any traffic coming in to the internal interface with a source IP from you NAT clients to be routed via IPtables.  I would issue a series of commands like this:

-----
# Set up some basic interface settings.
ifconfig $INet 0.0.0.0 up
ifconfig $LAN 0.0.0.0 up

# Let's establish our bridge.  (I like the name bri0 better than br0 but it makes no difference.)
brctl addbr bri0
brctl addif bri0 $INet
brctl addif bri0 $LAN

# Let's set up our bridge interface with external and internal IPs so we can NAT / route for the LAN.
ifconfig bri0.1 $INet_BRouter_IP
ifconfig bri0.2 $LAN_Router_IP

# Let's turn our bridge in to a bridging router by telling the bridge which packets it should NOT bridge and thus route.
ebtables -t BROUTE -A BROUTING -i $LAN -s $LAN_Subnet -j DROP

# Put your IPTables lines here like you normally would.
-----

This is just test and theoretical code but it should work for you.  If you compiled in support for "Bridged IP/ARP packets filtering" (as called per 2.6.13) you will have to enable forwarding support for the traffic coming in the bri0 interface that will be going back out the bri0 interface.  "Bridged IP/ARP packets filtering" is (as I understand it) the extension that allows IPTables to see the traffic that would be passing through the bridge thus allowing you to do many of the things that IPTables can do on a Layer 2 bridge / firewall.

# Accept bridged traffic that is coming in from the internet and going out to the LAN.
iptables -t filter -A FORWARD -i bri0 -o bri0 -m physdev --physdev-is-bridged --physdev-in $INet --physdev-out $LAN -j ACCEPT
# Accept bridged traffic that is coming in from the LAN and going out to the internet.
iptables -t filter -A FORWARD -i bri0 -o bri0 -m physdev --physdev-is-bridged --physdev-in $LAN --physdev-out $INet -j ACCEPT
# Accept traffic that is destined to one of the IPs assigned to the bri0 interface.
iptables -t filter -A FORWARD -i bri0 -o bri0 -d $INet_BRouter_IP -m physdev --physdev-is-in -j ACCEPT
iptables -t filter -A FORWARD -i bri0 -o bri0 -d $LAN_IP -m physdev --physdev-is-in -j ACCEPT
# Accept traffic that is from one of the IPs assigned to the bri0 interface.
iptables -t filter -A FORWARD -i bri0 -o bri0 -s $INet_BRouter_IP -m physdev --physdev-is-out -j ACCEPT
iptables -t filter -A FORWARD -i bri0 -o bri0 -s $LAN_IP -m physdev --physdev-is-out -j ACCEPT
# Note:  I'm not 100% sure about the --physdev-is-in and --physdev-is-out.  They may be backwards so play with them.

Of course if you just set a default policy of ACCEPT on the FORWARD chain then everything should get through unless you explicitly block it.

Would any one else care to checksum my thought proccess?  Please?



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc