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