Firewalling revisited...

Björn Lindberg d95-bli at nada.kth.se
Fri Oct 26 02:47:44 PDT 2001


Henning Rohde wrote:
> 
> Hi Björn,
> 
> Björn Lindberg wrote:
> > First of all, I really appreciate your feedback. it is an interesting
> > discussion.
> >
> 
> Thanks, I still may wonder why you're insisting on your current,
> inconventional concept, but discussing about its benefits and disadvantages
> may even widen the limits of my knowledge about firewalling and help me to
> improve the hint I wrote for BLFS.
> 
> BTW, did anyone read it? Did it prove at least readable, or even useful?

I read it; it's just that I wanted to try and design my own firewall, to
really learn about firewalling. The LFS bug you know, I always have to
do everything myself, in the most complicated way possible! ;-)

> > I agree that's probably safer. I suspect that tunneling X wouldn't work
> > that way though, especially since the router doesn't even run X.
> >
> Hmm, tell me, which way is this tunnel supposed to work:
> 1) you're sitting at school     or
> 2) you're sitting in front of your box at home?

Both ways. Right now it works perfectly. SSH tunnels an X connection
either way.

> >> The case I've been thinking about is, that you were having two clients
> >> behind your router:
> ...
> >> If you would do this without customizing your scripts
> >> $IPTABLES -t nat -A PREROUTING -i $EXTDEV -j DNAT --to 192.168.1.1
> >> would take precedence before the automatical 'back-route' you refered to,
> >> because it affects the packet _before_ routing.
> >> Because of this rule any data coming-in into the external interface of
> >> your router would be sent to your desktop, your mate might try to start a
> >> connection to any a website from his laptop, but he would not see any
> >> image.
> >
> > From Rusty's guide to NAT:
> >
> > "At each of the points above, when a packet passes we look up what
> > connection it is associated with. If it's a new connection, we look up
> > the corresponding chain in the NAT table to see what to do with it. The
> > answer it gives will apply to all future packets on that connection."
> >
> > So, although I haven't tried it, it seems to me that only the first
> > packet in a connection gets run through the NAT chains. Since the first
> > packet in those connections would emmanate from their respective boxes
> > (internal), the whole connection would follow that route.
> >
> 
> Please try it, it really would make me astonish if it worked!
> (It would be sufficient, if you changed the IP-address of your only client
> to, e.g., 192.168.1.2.)
> 
> The reason for my doubts is: by that line, the line I've cited last mail,
> you IMHO either
> 1) alter one of the decicive parameter the decision where to reNAT it is
> made on, or,
> 2) you overwrite that decision, or,
> 3) you bypass this automatic decision (my favourit explanation).
> 
> So, please do a try!

I will as soon as I get another box running. I don't see why it wouldn't
work though; according to Rusty's guides, the nat table only get to
handle initial packages for a connection, while the filter table get to
handle all arriving (or leaving) packets.

> BTW, did you know that your concept is not as inconventional as I once
> thought it to be: it is commonly used for loadbalancing!

Is it really that unconventional? Since I put this together from what
I've learned, I don't really know what is conventional.

How would you set it up if you had one IP, and wanted a firewall
protecting a web server and a box you needed to reach by ssh?


Björn
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list