Firewalling revisited...

Henning Rohde hr at our-home.net
Sat Oct 20 14:01:06 PDT 2001


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?

Sorry for the lag, I really had to get somethings done for my study of 
law...

> Henning Rohde wrote:
> 
>> > I agree. The reason I do it this way is because I want to be able to
>> > ssh into my internal box from the outside, eg from school. I also want
>> > to be able to run X clients through that ssh-tunnel.
>> 
>> Personally I prefer to do this in 2 steps: first log?in?to the router,
>> second into the client.
> 
> 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?

>> OK, that depends on your concept:
...
>> 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!

>> BTW, in one of my previous postings I asked you to verify your concept,
>> did it prove to work as you want it to?
>> E.g., ssh from school to your internal client, X11-forward, X11-tunnel
>> and so on...
> 
> I can ssh to school and back again. I can also start X clients on the
> school computer from home, and I can ssh back home again and start an X
> client. So I haven't actually tried it in front of a computer at school
> yet, but it seems to work.
> 

OK, that's nice, your concept seems to work correctly!

>> Do me a please and send me the output of a 'traceroute -v' to your
>> internal client, started on some box at school, I'm interested in the
>> responses your router and your client send.
> 
> I did this, but it didn't show anything particular, only that my IP
> recieved the packet. The router/internal box step wasn't visible. If you
> really want this log I can mail it to you.
> 

Thank you very much, I was interested in the "router/internal box step", it 
it was visible or not.


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

So long,

        Henning
-- 
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