All of lore.kernel.org
 help / color / mirror / Atom feed
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.


      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 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.