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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox