[LARTC] IP Tables on a bridge

[LARTC] IP Tables on a bridge

[ICI Support]

Not normally a question for this group, but you guys are very
bridge/router/firewall savvy, so I thought I'd toss it here.

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.

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.

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


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


-----

Michael Yacht
CTO
Ideal Conditions, Inc.
5329 Beeler Street, #2
Pittsburgh, PA 15217
v: 412-325-1375

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

Re: [LARTC] IP Tables on a bridge

[Corey Hickey]

ICI Support wrote:
> 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.
> 
> 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

If I tested this properly, it does seem to work. You could follow the
command above with whatever rules jumping to ACCEPT you want, ending
with a REJECT for whatever you don't want (or set the policy for FORWARD
to REJECT).

There are some other ways to do it. May I ask why this machine is a
bridge? My guess is that you have something like this:

[Internet] ----> T1 router ----> Linux bridge ----> LAN

...wherein the T1 router handles the routing to/from your public IPs and
your bridge handles the routing (with NAT) from your private IPs.

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

Sure; it couldn't hurt, unless someone nasty sees a flaw and tries to
attack one of your systems through it. :)

I'm going to be gone for several days, but I'll look at it when I get
back. Somebody else might look, too.

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

RE: [LARTC] IP Tables on a bridge

[ICI Support]

Corey, that is exactly why it is a bridge and precisely my setup, except
that I have a 8M/1M cable modem with 5 static IPs instead of a T1.  But,
effectively, it is the same.

If people could proof/suggest/comment on the script, I would appreciate it.
This is my first time using iptables.  In the past, I had a T1 line and I
used the cisco router as my firewall.

Below is my script:

--------------------------

# Do some initialization:


# Clear out the current settings:
iptables --flush
iptables -t nat --flush
iptables -t mangle --flush

iptables --delete-chain
iptables -t nat --delete-chain
iptables -t mangle --delete-chain

#---------------------------------------------------------------
# If a packet doesn't match one of the built in chains, then 
# The policy should be to drop it
#---------------------------------------------------------------

iptables --policy INPUT   DROP
iptables --policy OUTPUT  DROP
iptables --policy FORWARD DROP

# Loopback accepts all:
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


# Define some global variables:

# First define the interfaces
EXTERNAL_INT="eth0"
INTERNAL_INT="eth1"

# Now the machines on the inside.
BRIDGE_IP="70.89.224.61"
TESTBOX_IP="70.89.224.60"
WIN2K_IP="70.89.224.59"
MEATNOG_IP="70.89.224.58"
ICI_IP="70.89.224.57"
INTERNAL_NET="192.168.10.0/24"

# AEGIS's Firewall, going to accept all from this one.
AEGIS_IP="12.39.123.5"

# NAT
iptables -A POSTROUTING -t nat -o eth0 -s $INTERNAL_NET -d 0/0 -j MASQUERADE

iptables -A FORWARD -d $INTERNAL_NET -j ACCEPT

sysctl -w net.ipv4.ip_forward=1
echo 1 > /proc/sys/net/ipv4/ip_forward

# Allow all outgoing packets.  May want to filter this later.
iptables -A OUTPUT -o eth0 -j ACCEPT


# All internal IPs are assumed to be trusted.
iptables -A INPUT   -j ACCEPT -p all -s 192.168.10.0/24 -i eth1
iptables -A OUTPUT  -j ACCEPT -p all -d 192.168.10.0/24 -o eth1


# Let AEGIS reach the Win2k box.
iptables -A FORWARD -i eth0 -s $AEGIS_IP -d $WIN2K_IP -j ACCEPT



# SSH Access:
# SSH is on port 22, TCP

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 22 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 22 -j ACCEPT



# SMTP Access:
# SMTP is on port 25, TCP

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 25 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 25 -j ACCEPT



# DNS Access:
# DNS is on port 53, TCP/UDP

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 53 -j
ACCEPT
iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p UDP --dport 53 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p UDP --dport 53 -j ACCEPT




# HTTP Access:
# HTTP is on port 80

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 80 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 80 -j ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $WIN2K_IP -p TCP --dport 80 -j ACCEPT




# POP3 Access:
# POP3 is on port 110

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 110 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 110 -j ACCEPT



# AUTH Access:
# AUTH is on port 113.

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 113 -j
ACCEPT

iptables -A FORWARD -i eth0 -s 0/0 -d $ICI_IP -p TCP --dport 113 -j ACCEPT



# MUD Access:
# The Mud is on port 6250

iptables -A FORWARD -i eth0 -s 0/0 -d $MEATNOG_IP -p TCP --dport 6250 -j
ACCEPT



-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl]
On Behalf Of Corey Hickey
Sent: Wednesday, September 21, 2005 1:27 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] IP Tables on a bridge

ICI Support wrote:
> 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.
> 
> 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

If I tested this properly, it does seem to work. You could follow the
command above with whatever rules jumping to ACCEPT you want, ending
with a REJECT for whatever you don't want (or set the policy for FORWARD
to REJECT).

There are some other ways to do it. May I ask why this machine is a
bridge? My guess is that you have something like this:

[Internet] ----> T1 router ----> Linux bridge ----> LAN

...wherein the T1 router handles the routing to/from your public IPs and
your bridge handles the routing (with NAT) from your private IPs.

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

Sure; it couldn't hurt, unless someone nasty sees a flaw and tries to
attack one of your systems through it. :)

I'm going to be gone for several days, but I'll look at it when I get
back. Somebody else might look, too.

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

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

Re: [LARTC] IP Tables on a bridge

[Corey Hickey]

ICI Support wrote:
> Corey, that is exactly why it is a bridge and precisely my setup, except
> that I have a 8M/1M cable modem with 5 static IPs instead of a T1.  But,
> effectively, it is the same.

Back before I knew anything about this stuff my mentor set up a bridge
for exactly that reason. We had a setup similar to yours, but probably a
bit bigger -- 16 public IPs and around 100 private ones. Trouble was,
there was a lot of internal traffic between the public-IP machines and
the private-IP machines. Even though the two subnets were on the same
physical Ethernet they couldn't talk to each other directly because they
had no direct knowledge of each other. Thus, the Linux router was
routing all the traffic, which slowed everything down somewhat.


Our eventual solution was to take the following steps:

1. Assign the public machines IPs within a certain range of the
private-IP subnet _instead_ of directly using a public IP.

2. Assign the internal interface of the SDSL router a private IP in a
different range from what we were using for our LAN. Since we were using
10.0.0.0/8 for the LAN, we gave the router 192.168.0.1/24.

3. Likewise for the external interface of the Linux router: 192.168.0.2/24.

4. Set up a static route in the SDSL router to route any packets
destined for our public IPs to 192.168.0.2.

5. Set the default route in the Linux router to 192.168.0.1.

6. Set up NATting in the Linux router in such a way that any traffic to
the public IPs gets DNATted exclusively to the corresponding private IP,
and vice versa for traffic coming from the "special" private IPs. For
example:
private  <---> public
10.1.0.1 <---> 123.123.123.1
10.1.0.2 <---> 123.123.123.2

7. Implement a split-horizon DNS setup so internal clients would get the
servers' private addresses and external clients would get the servers'
public addresses.


Now, I'm not necessarily advocating such a setup to you. There are pros
and cons, and I thought you might be interested in knowing of an
alternate method.

Pro:
* Private and "public" machines are on the same subnet.
* The lowest IP of your public range no longer needs to be the network
address, and is now usable for a host.

Con:
* 75% of ISP tech support people don't know what to make of it.
* Split-horizon DNS can be more complex.


> If people could proof/suggest/comment on the script, I would appreciate it.
> This is my first time using iptables.  In the past, I had a T1 line and I
> used the cisco router as my firewall.
> 
> Below is my script:

I've cut out the parts I'm not commenting on.

> # NAT
> iptables -A POSTROUTING -t nat -o eth0 -s $INTERNAL_NET -d 0/0 -j MASQUERADE

"-d 0/0" is unnecessary, as that is the default.

> sysctl -w net.ipv4.ip_forward=1
> echo 1 > /proc/sys/net/ipv4/ip_forward

Don't these do the same thing? I've always just used echo.

> # All internal IPs are assumed to be trusted.
> iptables -A INPUT   -j ACCEPT -p all -s 192.168.10.0/24 -i eth1
> iptables -A OUTPUT  -j ACCEPT -p all -d 192.168.10.0/24 -o eth1

"-p all" is unnecessary. That's the default.


That's pretty much it -- your script is fairly simple and nothing looked
wrong to me. One thing that might reduce the load a bit:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

If you put that rule before your other filter rules, any packet that's
part of (or related to) an established connection will be accepted and
not have to traverse the rest of your rules.

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

RE: [LARTC] IP Tables on a bridge

[ICI Support]

Interesting idea, Corey.  I'll consider it.  It is the split-horizon DNS
that concerns me and has stopped me from doing that already.  Plus then
turning the bridge into a brouter too.   Thankfully there isn't too much
traffic between the local machines and the routable servers.  Most of the
traffic between them are NetBios-type connections.  All my servers have been
given local-IP aliases, and services like SMB and WFS are bound to those
local-IP aliases (also ensuring that the external IPs can't do those
things).

Thanks for proofing my script.  Glad it looks right.  It is the first
iptables script I've made.  I know a few of the params are unneeded, but I'm
a big fan of explicitly setting options.  Keeps me sane when I have to go
back and look at them 6 months later.

Also, don't get me started about ISP tech support.  My ISP is Comcast and
half the time I feel like I am educating them whenever I call.   The whole
reason I'm doing this (moving the firewall from the router/modem to the
bridge) is because I was told that the modem is sometimes 'unstable' if used
as a firewall too.   So now I'm trying to reduce that modem down as far as
possible to a dumb modem.


- Mike 

-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl]
On Behalf Of Corey Hickey
Sent: Wednesday, September 21, 2005 3:35 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] IP Tables on a bridge

ICI Support wrote:
> Corey, that is exactly why it is a bridge and precisely my setup, except
> that I have a 8M/1M cable modem with 5 static IPs instead of a T1.  But,
> effectively, it is the same.

Back before I knew anything about this stuff my mentor set up a bridge
for exactly that reason. We had a setup similar to yours, but probably a
bit bigger -- 16 public IPs and around 100 private ones. Trouble was,
there was a lot of internal traffic between the public-IP machines and
the private-IP machines. Even though the two subnets were on the same
physical Ethernet they couldn't talk to each other directly because they
had no direct knowledge of each other. Thus, the Linux router was
routing all the traffic, which slowed everything down somewhat.


Our eventual solution was to take the following steps:

1. Assign the public machines IPs within a certain range of the
private-IP subnet _instead_ of directly using a public IP.

2. Assign the internal interface of the SDSL router a private IP in a
different range from what we were using for our LAN. Since we were using
10.0.0.0/8 for the LAN, we gave the router 192.168.0.1/24.

3. Likewise for the external interface of the Linux router: 192.168.0.2/24.

4. Set up a static route in the SDSL router to route any packets
destined for our public IPs to 192.168.0.2.

5. Set the default route in the Linux router to 192.168.0.1.

6. Set up NATting in the Linux router in such a way that any traffic to
the public IPs gets DNATted exclusively to the corresponding private IP,
and vice versa for traffic coming from the "special" private IPs. For
example:
private  <---> public
10.1.0.1 <---> 123.123.123.1
10.1.0.2 <---> 123.123.123.2

7. Implement a split-horizon DNS setup so internal clients would get the
servers' private addresses and external clients would get the servers'
public addresses.


Now, I'm not necessarily advocating such a setup to you. There are pros
and cons, and I thought you might be interested in knowing of an
alternate method.

Pro:
* Private and "public" machines are on the same subnet.
* The lowest IP of your public range no longer needs to be the network
address, and is now usable for a host.

Con:
* 75% of ISP tech support people don't know what to make of it.
* Split-horizon DNS can be more complex.


> If people could proof/suggest/comment on the script, I would appreciate
it.
> This is my first time using iptables.  In the past, I had a T1 line and I
> used the cisco router as my firewall.
> 
> Below is my script:

I've cut out the parts I'm not commenting on.

> # NAT
> iptables -A POSTROUTING -t nat -o eth0 -s $INTERNAL_NET -d 0/0 -j
MASQUERADE

"-d 0/0" is unnecessary, as that is the default.

> sysctl -w net.ipv4.ip_forward=1
> echo 1 > /proc/sys/net/ipv4/ip_forward

Don't these do the same thing? I've always just used echo.

> # All internal IPs are assumed to be trusted.
> iptables -A INPUT   -j ACCEPT -p all -s 192.168.10.0/24 -i eth1
> iptables -A OUTPUT  -j ACCEPT -p all -d 192.168.10.0/24 -o eth1

"-p all" is unnecessary. That's the default.


That's pretty much it -- your script is fairly simple and nothing looked
wrong to me. One thing that might reduce the load a bit:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

If you put that rule before your other filter rules, any packet that's
part of (or related to) an established connection will be accepted and
not have to traverse the rest of your rules.

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

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

Re: [LARTC] IP Tables on a bridge

[Grant Taylor]

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