From: "Lluís Batlle" <viriketo@gmail.com>
To: /dev/rob0 <rob0@gmx.co.uk>, netfilter@lists.netfilter.org
Subject: Re: Problem with routing decisions, and multihop
Date: Mon, 4 Jul 2005 18:54:50 +0200 [thread overview]
Message-ID: <45219fb005070409543f229ddd@mail.gmail.com> (raw)
In-Reply-To: <200507041133.35774.rob0@gmx.co.uk>
Thanks :) I answer between lines...
On 7/4/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> >>="masquerading.multi-eth" (misnamed: it does no masquerading)
Ok. I tried with MASQUERADE, but by now I use SNAT.
>
> >>NE1=192.168.16.0/28
> >>NE2=192.168.17.0/28
>
> Let's see, those are .0-.15 on the last quad.
>
> >>NLOCAL=192.168.0.0/20
>
> And this is 0.0 through 15.255 ... IOW, wrong, excluding both $NE1 and
> $NE2. Try 192.168.16.0/23. It would not hurt for you to brush up on
> TCP/IP and subnetting basics.
Oh. Is it wrong? I don't understand what's "IOW". Where should I try
your proposed subnet? why?
>
> >> $IPTABLES -t nat -F PREROUTING
> >> $IPTABLES -t nat -F POSTROUTING
> >> $IPTABLES -t nat -F OUTPUT
> >> $IPTABLES -t filter -F INPUT
> >> $IPTABLES -t filter -F FORWARD
> >> $IPTABLES -t filter -F OUTPUT
> >> $IPTABLES -t filter -F keep_state >&/dev/null
> >> $IPTABLES -t filter -X keep_state >&/dev/null
> >> $IPTABLES -t nat -F keep_state >&/dev/null
> >> $IPTABLES -t nat -X keep_state >&/dev/null
>
> Could be rewritten as:
> iptables -F ; iptables -X ; iptables -t nat -F ; iptables -t nat -X
Ok :)
>
> >> $IPTABLES -t filter -N keep_state
> >> $IPTABLES -t filter -A keep_state -m state \
> >> --state RELATED,ESTABLISHED -j ACCEPT
> >> $IPTABLES -t filter -A keep_state -j RETURN
> >>
> >> $IPTABLES -t nat -N keep_state
> >> $IPTABLES -t nat -A keep_state -m state \
> >> --state RELATED,ESTABLISHED -j ACCEPT
> >> $IPTABLES -t nat -A keep_state -j RETURN
>
> 1. IMO it's confusing to give chains the same name in different tables.
I agree... but by now does that matter?
> 2. The RETURN rules are pointless. That's what happens at the end of a
> chain, anyway.
Ok. That's what I thought
> 3. --state in -t nat? Is that possible? Does it work? Does it break
> anything?
It seems it's possible. I get no error from those commands. Anyway,
I've thought that happens double application of that rule, through
filter and nat tables. I've removed everything about 'keep_state' in
the nat table. Everything is still working bad. Even from the computer
itself (local processes). Routing doesn't work, even without any
"NAT"-related chain/rule.
>
> > About the 16.x and 17.x addresses... yes, there are other routers,
> > which make NAT (192.168.16.2 and 192.168.17.2) to internet.
>
> This seems odd to me. I prefer to use external IP directly, for many
> reasons. It also eliminates other potential points of failure.
I agree :) but it's hard for me to configure the routers, so they give
to me the public addresses. I think that double-NAT should not break
anything. :)
>
> It's even more odd considering that you're doing DNAT on the already-
> NAT'ed Linux machine. Why not do the DNAT in the external routers?
> Also, those DNAT rules refer to other RFC 1918 netblocks.
mmm I've never read RFC 1918. :) I'll take a look at it.
Thanks!
- I finish the working time in few minutes. Tomorrow morning I'll keep
on with this.
next prev parent reply other threads:[~2005-07-04 16:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-04 14:15 Problem with routing decisions, and multihop Lluís Batlle
2005-07-04 14:21 ` Lluis Batle
2005-07-04 14:32 ` Lluis Batle
2005-07-04 15:07 ` /dev/rob0
2005-07-04 15:10 ` /dev/rob0
[not found] ` <45219fb005070408323197bfa4@mail.gmail.com>
2005-07-04 15:32 ` Lluis Batle
2005-07-04 16:33 ` /dev/rob0
2005-07-04 16:54 ` Lluís Batlle [this message]
2005-07-04 18:06 ` /dev/rob0
2005-07-05 5:52 ` Lluís Batlle
2005-07-05 7:46 ` Problem with routing decisions, and multihop (solved) Lluís Batlle
-- strict thread matches above, loose matches on Subject: below --
2005-07-04 14:52 Problem with routing decisions, and multihop LluÃs Batlle i Rossell
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=45219fb005070409543f229ddd@mail.gmail.com \
--to=viriketo@gmail.com \
--cc=netfilter@lists.netfilter.org \
--cc=rob0@gmx.co.uk \
/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.