From: "Gáspár Lajos" <swifty@freemail.hu>
To: Marco Nicoloso <nicolm@gmail.com>,
Netfilter IPtableMailinglist <netfilter@lists.netfilter.org>
Subject: Re: Cannot go out the firewall from internal network (NAT)
Date: Wed, 15 Nov 2006 09:02:23 +0100 [thread overview]
Message-ID: <455AC98F.3090606@freemail.hu> (raw)
In-Reply-To: <e8c943190611141158x489ed2feh36fe6fad2cb2fdc8@mail.gmail.com>
Marco Nicoloso írta:
>
> 1) POSTROUTING chain is processed after the FORWARD chain, isn't it?
Yes
> But do I really need the FORWARD chain? If yes, do I need to setup my
> rules for filtering the packets coming from my LAN which I want to
> pass through the firewall (using a DROP policy) in the FORWARD or just
> in the INPUT chain, or in both of them?
In the FORWARD chain you filter the packets passing througth the firewall...
In the INPUT chain you filter the packets sent to your firewall... (For
example to a DNS server that sits on your firewalling machine...)
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
>
> 2) Which is the right place for the NATting rules in my script? That
> is, NAT rules must be placed before or after PF rules (for me after,
> but as NAT controls different chains because `nat' is a different
> table... maybe it's the same)
There are chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) and
tables (-t raw, -t mangle, -t nat, -t filter <-(default) )
http://www.faqs.org/docs/iptables/traversingoftables.html
NAT rules ARE placed before (PREROUTING) and after (POSTROUTING) PF rules...
Take a look on what you have already done with these commands:
iptables -vnL -t nat
iptables -vnL
iptables -vnL -t mangle
>
> 3) Someone can verify the following sentence if I understood
> correctly: "Packet coming from any network connected to the firewall
> enters the chain INPUT:
The correct route:
mangle PREROUTING
nat PREROUTING
[Routing decision]
mangle INPUT
filter INPUT
[Local process]
> rules are processed from the first in order to
> the end,
yes
> if a suiting rule for it is found, then the faith of the
> packet depends only on that rule;
yes
> if not packet is either dropped or
> accepted, depending on the general policy of the chain
yes
Rules that you may think about (What I prefer :D ):
- The chain policy should be always ACCEPT except in the filter tables...
- DROP-ing or REJECT-ing should me always done in the filter tables...
- Using user-defined chains makes the iptables run faster...
Also take a look on my script.... :)
https://lists.netfilter.org/pipermail/netfilter/2006-August/066404.html
Swifty
next prev parent reply other threads:[~2006-11-15 8:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 15:15 Cannot go out the firewall from internal network (NAT) Marco Nicoloso
2006-11-13 15:39 ` Tommy W
2006-11-13 16:09 ` Marco Nicoloso
2006-11-14 11:34 ` Pradeep Jindal
2006-11-14 19:58 ` Marco Nicoloso
2006-11-15 8:02 ` Gáspár Lajos [this message]
2006-11-15 17:44 ` Pradeep Jindal
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=455AC98F.3090606@freemail.hu \
--to=swifty@freemail.hu \
--cc=netfilter@lists.netfilter.org \
--cc=nicolm@gmail.com \
/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.