From: Daniel Lopes <lopsch@lopsch.com>
To: netfilter@lists.netfilter.org
Subject: Re: GRE over two NATs
Date: Tue, 05 Apr 2005 01:36:49 +0200 [thread overview]
Message-ID: <4251CF91.2030509@lopsch.com> (raw)
In-Reply-To: <20050404190444.GA22407@epsilon.rdc.pl>
Mariusz Kruk schrieb:
> I have a router with 4 interfaces on which I prepared a "IMQ without IMQ
> setup". Long story short - every packet that traverses the router is
> first pushed through a tunnel set up between 127.0.0.2 and 127.0.0.3.
> Therefore I can easily shape the trafic for all interfaces.
>
> It looks like this (one interface only for simplicity):
>
> localnet --- eth3 --- localend <---------> remoteend --- eth0 --- world
>
> Where localnet is of course my local network, eth3 is a local interface,
> localend is a "local" end of the tunnel, and so on.
> I use NAT and therefore I have to NAT every packet twice, since... I
> don't exactly remember what was the exact reason but it had something to
> do with connection tracking. Anyway, my 192.168.0.0/16 local addresses
> are first mapped 1-to-1 to 172.16.0.0/16 addresses and finally all are
> mapped to my public IP.
> Everything runs well except GRE.
> My users complained that they can't connect to their VPNs over PPTP.
> PPTP uses GRE, so I started to log packets in various tables.
> I found that for a GRE packet generated in localnet it goes like this:
> eth3, mangle/prerouting, mangle/forward, filter/forward, mangle/postrouting,
> nat/postrouting, localend.
> Then the packet gets in the box again from the remoteend end of the
> tunnel and, surprisingly to me, gets logged at mangle/prerouting and
> nat/prerouting(!).
>
> Why is it so?
> I won't be attaching my setup here since it is generated from a script
> and has quite a few hundred rules (yes, I know it's not veryeffective,
> but I wanted to have a vanilla kernel, and it's kind of a
> proof-of-concept), but there is no rule that should filter such packets.
> There is no rule in nat/prerouting table that applies to those packets.
> I have completely no idea. :-(
I don´t really understand your setup so far but for GRE to work behind
NAT you need connection tracking modules because afaik there´s nothing
like NAT-T for GRE like for IPSec. I hope I´m not totally telling you
nonsense. For PPTP and GRE there are conntrack modules in POM-NG.
prev parent reply other threads:[~2005-04-04 23:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-04 19:04 GRE over two NATs Mariusz Kruk
2005-04-04 23:36 ` Daniel Lopes [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=4251CF91.2030509@lopsch.com \
--to=lopsch@lopsch.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox