/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting!
/* ALSO: Don't quote this header. It makes you look lame :-) */
Timothy Hamlin <[EMAIL PROTECTED]> wrote:
>
> I have just started to make the transition from ipchains to iptables, and
> am trying to get the following setup working:
Unfortunately, you will probably have to unlearn most everything you
ever knew about ipchains, when working with iptables. In particular,
the number of tables is quite a bit larger, and learning which rules go
in which tables is important. Also, the state machine (the list of
tables that will be traversed by a packet traveling through the system)
is different.
A good example is the INPUT ruleset which you used in your example:
> $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $UNIVERSE -j ACCEPT
>
> +add additional nets as in:
> $IPTABLES -A INPUT -i $INTIF -s $INTNET_1 -d $UNIVERSE -j ACCEPT
> $IPTABLES -A INPUT -i $INTIF -s $INTNET_2 -d $UNIVERSE -j ACCEPT
> $IPTABLES -A INPUT -i $INTIF -s $INTNET_3 -d $UNIVERSE -j ACCEPT
These rules will not work! They specify traffic that is traveling from
one interface to another. Such traffic will never be passed by the
INPUT ruleset. Instead, it will be passed by the FORWARD rules. This
is a major difference from ipchains.
In iptables, the only use for the INPUT ruleset is for the purpose of
filtering traffic that is directed at the router itself.
Another difference from ipchains is that the specification of which
traffic to NAT is not performed in the FORWARD rules. It's not even
specified in the "filter" table (where the INPUT and FORWARD rules are
kept), but in the "nat" table, which has its own set of rules.
The "nat" table rules are labeled as "PREROUTING" and "POSTROUTING" so
that you will get the idea that the table will be modifying the packets
BEFORE or AFTER they are witnessed by the INPUT rules or the FORWARD
rules in the filter table. You must keep the NAT changes in mind when
you are deciding what rules to put in your filter table. And we haven't
even talked about the "mangle" table, where the same rules apply...
Now, maybe you do really know all this, but I think it bears repeating
for the other folks on this list who are trying to learn. I was one of
them, not too long ago. :)
> Now, masquerading traffic for the network associated with eth0 on
> router2 works fine, just as I would expect. What I want to do, is get
> router1 to MASQ traffic properly for all the networks behind router2,
> not just the network associated with eth0, I can only get it working
> properly for the primary internal network.
One of the things you'll find is that because of the new structure, you
may be able to write a lot SIMPLER set of rules under iptables, that are
just as effective as the COMPLEX rules you used under ipchains. For
instance, your INPUT and FORWARD (filter) rules can be written to only
deal with Policy (what we allow, what we don't allow), while the nat
rules can deal with what has to be NAT'ed, without worrying about policy.
As an example, here's my NAT rule in the nat table:
iptables -t nat -A POSTROUTING -o $EXT_IF -j SNAT --to $EXT_IP
Yep, that's it. Doesn't matter how many internal interfaces I have,
doesn't matter where the traffic came from, if it's going out the
external interface, it gets NAT'd to the external IP. Simple! The
other Policy-based decisions (who is allowed to reach the router? which
networks can pass through, in which directions?) are handled by the
filter table. No need to clutter things here.
An important thing to remember, when constructing the filter table, is
that a packet will either pass the INPUT rules *OR* the FORWARD rules,
but never both. This is a major departure from ipchains. If you are
used to writing all your INPUT rules to implement policy, you will have
to move or duplicate a lot of them into the FORWARD ruleset in order to
have them work.
One of the features of this scheme, though, is that you can set up a
simple rule like this:
iptables -A INPUT -i $EXT_IF -j DROP
That's a simple rule. No one on the internet can talk to my router AT
ALL. Now, you might think that a rule like this will stop your internet
connection from working! But it will not. It will only stop traffic
that is directed at the router, for the purpose of talking to the
router. For instance, NAT'd traffic will still be un-NAT'd as it enters
the router (because that is handled as a mangle PREROUTING stage), and
then the routing decision will cause the router to determine that the
traffic is being FORWARDed through the router. Therefore, FORWARDed
traffic will pass the FORWARD rules, not the INPUT rules. So traffic
will still flow THROUGH the router, but will not terminate TO the
router, from the internet.
Similarly, a simple forwarding ruleset like this might be enough for
your needs:
iptables -A FORWARD -i $EXT_IF -m state \
--state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o $EXT_IF -m state \
--state NEW,ESTABLISHED,RELATED -j ACCEPT
In other words, traffic forwarding through, coming IN the external side,
will be allowed if it's related to an existing connection. Traffic
going OUT will be allowed for any connection. If your policies are
open, then this is all you need to set up the router. Iptables'
stateful packet inspection will keep any other traffic out, if it's not
related to things that your network has requested.
Hmm.. I seem to have gotten a bit off the subject, but perhaps this has
answered your question somehow..? :)
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Good judgment comes from experience.
sometimes known as David DeSimone || Experience comes from bad judgment."
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ --
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
