> cable dsl
> ports \ / all other
> 21,80 router ports
> |
> net
Routing - figures out which interface to send a packet through, based upon ip
address space.
nat - mangles packets by replacing source and destination (or other)
ip information.
default gateway - the ip address to send all packets destined for non
adjacent ip networks (ie all networks your box is not on).
Netfilter in linux 2.4 can easily mangle your packets, such that they
appear to come from the cable-ip on ports 21 and 80; and from the dsl-ip
on all other ports.
# Source NAT private lan to outside: ports 21,80
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP \
--dport 21 -j SNAT --to-source $cableIP
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP \
--dport 80 -j SNAT --to-source $cableIP
# Source NAT private lan to outside: all other traffic
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP -j SNAT \
--to-source $dslIP
This will be done after routing, however (POSTROUTING). Which means it
has already determined that www.google.com:80 is not on a local lan, and
thus needs to be sent to the default gateway (dsl). So, while the
packet is mangled to look like it is coming from your cable-ip, it will
be sent out your dsl line, and in effect be spoofed. Google will then
respond to it, however the response will come on your cable line.
Whether or not your system understands that the response it got on the
cable line is the answer to it's query on the dsl line is dependent upon
how clever the developers of the IP stack are.
Most likely, your IP stack will be looking for the response on the dsl
line, since that is where it left. So in effect your firewall will be
pinging google, google will be responding to the left ear(nic), but your
firewall will be listening to its right ear, meanwhile wondering what
this junk data is on it's left ear.
However, netfilter(NAT/packet filtering) is layered so very well that
one can work with firewall rules on an IP only layer, completely
ignoring interfaces. NAT works seamlessly with routing: either can be
configured without considering the other. It is possible that the
kernel developers may have layered the ip stack in a similar manner,
allowing this to work. Basically, if it were to work the ip stack would
record "I sent a [mangled] packet from cable-ip to google.com. I am
waiting for a response on cable-ip". However if the ip stack records
entries like this: "I sent a packet from cable-ip on dsl-interface to
dsl-router for google.com. I am waiting a response on dsl-interface,
from dsl-router and google.com with cable-ip", it probably won't work.
If this smart layering is the case, the script below should work fine
for a small network with private IPs on the internal lan (ie a 10.x
network). If you don't have a private internal lan, the forward chain
(for forwarding packets) should be tightened.
With this script, the firewall would have two public IP addresses: dslIP
and cableIP, as well as a private IP. This can all be accomplished with
1, 2 or 3 nics. You will use IP aliasing (available in the kernel) for
less than 3 nics (I use ip aliasing on a box with 2 nics and 6 ips).
Note the rule set below does not reference any interfaces at all.
Your default gateway should be set to the dsl line.
Good luck! I would like to know if it works.
Cory
privateIP="10.0.0.0/8"
# Note: 10.x.x.x
dslIP="1.2.3.4"
cableIP="5.6.7.8"
# Filter Table #
iptables -F
iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow internal lan to ssh in to firewall
iptables -A INPUT -s $privateIP -p tcp --dport 22 -j ACCEPT
# NAT Table #
iptables -F -t nat
# Source NAT private lan to outside: ports 21,80
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP \
--dport 21 -j SNAT --to-source $cableIP
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP \
--dport 80 -j SNAT --to-source $cableIP
# Source NAT private lan to outside: all other traffic
iptables -t nat -A POSTROUTING -s $privateIP -d ! $privateIP -j SNAT \
--to-source $dslIP
On Wed, Jan 30, 2002 at 07:04:34PM -0800, Jacob Meuser wrote:
> On Wed, Jan 30, 2002 at 05:43:07PM -0800, Mark Bigler wrote:
>
> > I'd sure think that pf would do
> > all they want and more.
>
> > > > We have a box that acts as our uber router that will have a
> > > > wireless nic, wired nic, nic for the dsl, and nic for the cable.
> > > > It will be doing nat/firewall and dhcp. Thats about it. Is there
> > > > anyway to tell
> > > > the machine to send all packets on ports 21 and 80 through the
> > > > cable and everything else through the DSL?
>
> You mean like this?
>
> cable dsl
> ports \ / all other
> 21,80 router ports
> |
> net
>
> I don't think it's possible with pf. The kernel would have to
> route by port to route the packet through the right NIC.
>
> That's not what NAT does. It changes the source and/or destination
> IP address. Sure, it can do this selectively by port, but that's
> not the same thing.
>
> It may be possible with NAT and ALTQ combined, but I haven't looked
> much at what ALTQ is capable of.
>
> These types of ideas come up with some frequency on the [EMAIL PROTECTED]
> ml -> http://marc.theaimsgroup.com/?l=openbsd-misc
>
> --
> <[EMAIL PROTECTED]>
