All of lore.kernel.org
 help / color / mirror / Atom feed
From: "former03 | Baltasar Cevc" <baltasar.cevc@former03.de>
To: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
Cc: netfilter@lists.netfilter.org
Subject: Re: no ssh on eth0
Date: Mon, 31 Jul 2006 17:51:25 +0200	[thread overview]
Message-ID: <a74803cb862d9adbddb9a6ea3ca6eeea@former03.de> (raw)
In-Reply-To: <44CE0921.7050103@plouf.fr.eu.org>


On 31.07.2006, at 15:44, Pascal Hambourg wrote:

> former03 | Baltasar Cevc a Ècrit :
>>> Why ? What is the difference with or without NAT ?
>> You can filter out all incoming packets to local IP addresses on the 
>> wan interface before NAT is done;
>
> No you can't, unless you intend to do filtering in PREROUTING chain of 
> the 'mangle' table.
I'd probably prefer to do it in the nat table (well, I do know that 
filtering should be done in filter only, but it works well that way, 
too). Another option would be to separate it using marks.

And for local host access, which was what we were talking about:
    -t filter -A INPUT -i eth0 -d <local ip> -j REJECT --reject-with 
icmp-network-unreachable

>
>> if you just use MASQUERADE for outgoing packets, "iptables -A INPUT 
>> -i eth0.-d 192.168.0.0/16 -j DROP".
>
> I just don't see how it is different whether you have NAT/MASQUERADE 
> or not. To me filtering and NAT in iptables are fundamentally 
> independent.
Sure, they are. However, if I nat, I can make the following assumption:
there are no (valid) packet addressed to internal addresses on eth0.
Which is something I can't assume when I don't have NOT. WIthout that 
assumption, I cannot prohibit as much as I can when I assume that.

Baltasar


--

Baltasar Cevc

_____ former 03 gmbh
_____ infanteriestrafle 19 haus 6 eg
_____ D-80797 muenchen

_____ http://www.former03.de



  reply	other threads:[~2006-07-31 15:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-30  6:01 no ssh on eth0 varun
2006-07-30 10:12 ` Graham Murray
2006-07-30 11:44   ` Jan Engelhardt
2006-07-30 12:37     ` Pascal Hambourg
     [not found]       ` <facccfbd353e38901017e6dee5a54a99@former03.de>
     [not found]         ` <44CCE712.4070907@plouf.fr.eu.org>
2006-07-30 17:17           ` former03 | Baltasar Cevc
2006-07-30 20:04             ` Pascal Hambourg
2006-07-30 22:57               ` former03 | Baltasar Cevc
2006-07-31 13:44                 ` Pascal Hambourg
2006-07-31 15:51                   ` former03 | Baltasar Cevc [this message]
     [not found]                     ` <44CE7878.2020007@rtij.nl>
2006-07-31 21:54                       ` former03 | Baltasar Cevc
2006-08-02 14:15             ` varun
2006-07-30 10:41 ` Michael Weinert
2006-07-31 15:29   ` varun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a74803cb862d9adbddb9a6ea3ca6eeea@former03.de \
    --to=baltasar.cevc@former03.de \
    --cc=netfilter@lists.netfilter.org \
    --cc=pascal.mail@plouf.fr.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.