Firewalling revisited...

Henning Rohde hr at
Thu Oct 18 08:46:34 PDT 2001

Hi Björn, 
hi everybody else,

Björn Lindberg wrote:
> Henning Rohde wrote:
>> In your current setup you DNAT any incoming request to your internal
>> client. Doing it this way, you do not use the highly apprechiated feature
>> the conventional concept of a masquerading router has:
>> The conventional concept means, that the masqerading router does only
>> SNAT outgoing requests, incoming requests are handelt by itself.
>> If some cracker attacked your IP, he would only be able to crack the
>> router with no important data on it, but he would not get immediately 
>> full access to your documents. To access your documents he would need to
>> crack your internal machine as well.
>> In your current concept a cracker who ssh'ed to your IP would get the
>> login-prompt of your internal box. Cracking ssh seems quite unlikely,
>> but to login is not so difficult if you happen to have accounts with
>> weak passwords.
> 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. 
You've asked for comments, I've told you my thoughts, you're free to do 
what you consider to be best / to implement it on your own taste or 

> That is also partly why I divide it in two scripts. The nat table now
> exclusively handles routing, and the filter table handles firewalling.

Again, you're free how to realize your concept.

> On the other hand, I really don't see the difference though. If I
> instead allow ssh-connections to my router, and then from my router to
> my internal box, the cracker only has to log in twice. I mean, if he
> cracks my router, he would just have to log in to my internal box.

But he must guess two, hopefulle different, passwords to do the login, 
sorry for not having been unambiguous.

>> The other disadvantage, you concept has in my eyes, is that it allows
>> only one client: What are you going to do if you'd like to put a second
>> machine into your internal network, e.g., a notebook.
>> Any connection initiated from the notebook would correctly be routed into
>> the internet, but the answers would be redirected to,
>> wouldn't they?
> Well, yes and no. As I understand it, the nat table routes the first
> packet of a connection, and then automatically routes the rest of the
> packets in that connection accordingly. So, let's say I had another
> internal box, which I run a web server on. I would be able to make
> external connections from that box, and that whole session would get
> routed properly, or at least that's my understanding. Then to be able to
> visit my web server from the outside, I would route port 80 the same way
> I now route port 22, to the internal web server box.
> What do you think?

OK, that depends on your concept:
If you put a second machine into your net and start a webserver on it, 
everything is OK after you've altered your routing-scripts:

iptables -t nat -A PREROUTING -i $EXTDEV --dport 80 -j DNAT --to
iptables -t nat -A PREROUTING -i $EXTDEV --dport !80 -j DNAT --to192.168.1.1

The case I've been thinking about is, that you were having two clients 
behind your router:
Consider you're surfing at your desktop and your best friend is sitting 
infront of his notebook, both of you compete in finding the bestlooking 
girl in the whole internet!     ;-)

If you would do this without customizing your scripts
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.

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

Have a nice day,


Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list