rohde.henning at gmx.net
Sat Oct 27 11:02:57 PDT 2001
hi everybody else,
Björn Lindberg wrote:
> Henning Rohde wrote:
>> 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! ;-)
Yes I know that, it has been my own attitude for a long time now, but the
more expirenced I get the more I've to admit that simlicity pays out:
- Errors / pitfalls are easier tracked.
- I do not have to document any so little tweak anymore for the moment that
somebody else but me gets involved
(he's asked for his oppinion or for help / he wants to adopt my setup / the
setup needs to be enhanced but I'm far away so he is in charge ...)
>> > 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.
Congratulations, everything you want to work is OK, that the think I call
>> >> 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.
Hmm, I know, but I still think that it won't work because you alter the
header of incoming IP-packet _before_ routing, so your second box won't
receive a packet it could recognize to be addressed for itself.
Please tell me your further expirences, I'm still interested in them, but,
please mail me personally, our thread was last night nearly cut-off by
'texpire', so let's continue our discussion off-list.
>> 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?
Hmm, for this 'inconventional' case you're right, you have chosen the
Inconventional means in this case that a webserver is to be addressed by
the IP-address of the firewall: I was thinking that the firewall had to
protect some surfing client.
IIRC you've said in your initial posting that a 'workstation' was to be
protected, not a webserver: that was the reason for my irritations!
Now that everything has cleared up, every misunderstanding is solved, I can
tell you that I do not see any pitfalls in your concept, as long as you
stay with "a firewall protecting a web server and a box reachable by ssh"
and do not go beyound.
Have a nice weekend,
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