From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: philosophical question regarding NAT
Date: Tue, 10 May 2005 17:11:03 -0500 [thread overview]
Message-ID: <42813177.9030903@riverviewtech.net> (raw)
In-Reply-To: <1115723584l.29661l.0l@server.moose.blogdns.org>
> Although NAT is enabled and LAN side systems will be NATed to the
> gateway's WAN side IP address, WAN side systems can still access systems
> on the inside of the firewall if they know what the LAN side addresses
> are (and have a route to the gateway somehow).
>
> In other words, even though NAT is active the bridging function provided
> by ip_forward is still happening as well.
>
> It seems you can disable the bridging function with the following
> PREROUTING rule:
>
> -A PREROUTING -i eth0 -d <private_lan_block> -j DROP
>
> which enforces NAT, ie, only NATed things can get through. While you
> can achieve the same thing by setting policy of FORWARD to DROP and
> allowing only RELATED and ESTABLISHED stuff through (which I do)
> I am surprised I have not seen this PREROUTING rule used more often as a
> safety measure.
>
> It doesn't seem to break anything, does anyone know why this technique
> isn't seen more often?
Usually (as far as I know any way) there are accompanying rules that will only allow any traffic form the internal LAN to pass out to the internet (assuming that you don't want to do any Q & A filtering) and ONLY allow ESTABLISHED and RELATED stateful traffic back in from the internet to the internal LAN. If you have corresponding INPUT rules on your firewall I think that a LOT of what you are thinking about will be stopped at the firewall it's self. To my knowledge this is what the statful matching is for. Does any one care to comment on this?
Grant. . . .
prev parent reply other threads:[~2005-05-10 22:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-10 11:13 philosophical question regarding NAT Ian Laurie
2005-05-10 11:25 ` Vasilii.Alferov
2005-05-11 9:12 ` Ian Laurie
2005-05-10 11:26 ` Problem adding connlimit rule Ruben Cardenal
2005-05-10 13:11 ` philosophical question regarding NAT Francesco Ciocchetti
[not found] ` <20050510112649.07D4458F@mail.817west.com>
2005-05-10 13:45 ` Problem adding connlimit rule Jason Opperisano
2005-05-10 22:11 ` Taylor, Grant [this message]
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=42813177.9030903@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@lists.netfilter.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.