All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mart Frauenlob <mart.frauenlob@chello.at>
To: Pascal Hambourg <pascal@plouf.fr.eu.org>, Jan Niggemann <jn@hz6.de>
Cc: mart.frauenlob@chello.at, netfilter@vger.kernel.org
Subject: Re: conntrack GRE behaves differently in 3.17 / 3.18
Date: Sat, 24 Jan 2015 00:20:47 +0100	[thread overview]
Message-ID: <54C2D74F.6040800@chello.at> (raw)
In-Reply-To: <54C15E96.9060708@plouf.fr.eu.org>

On 22.01.2015 21:33, Pascal Hambourg wrote:
> Mart Frauenlob a écrit :
>> On 22.01.2015 08:55, Jan Niggemann wrote:
>>> Zitat von Pascal Hambourg <pascal@plouf.fr.eu.org>:
>>>
>>>> I do not see nf_conntrack_pptp here. It is required so that the first
>>>> GRE packet has the RELATED state.
>>>
>>> I had forgotten about that one.
>>>
>>> OK, so do I get this right:
>>>   From kernel 3.18 onwards I have to take care to first load the
>>> extension modules and only then create the pptp vpn connection?
>
> I just compared the conntrack states of GRE packets with a pre-3.18
> kernel (3.2.x) and a 3.18.3 kernel to check the effect of the change
> pointed to by Mart.
>
> As expected, with the 3.2.x kernel :
> - if neither nf_conntrack_proto_gre nor nf_conntrack_pptp are loaded,
> the first GRE packet of a plain GRE tunnel (as set by ip tunnel) or a
> PPTP connection is NEW ;
> - if only nf_conntrack_proto_gre is loaded, the first GRE packet of a
> plain GRE tunnel or a PPTP connection is NEW ;
> - if both nf_conntrack_proto_gre and nf_conntrack_pptp are loaded, the
> first GRE packet of a plain GRE tunnel is NEW and the first GRE packet
> of a PPTP connection is RELATED ;
> - in all cases, the first GRE reply packet (opposite direction to the
> first GRE packet) and all subsequent packets in either direction are
> ESTABLISHED.
>
> What has changed with the 3.18.x kernel : if neither nf_conntrack_pptp
> nor nf_conntrack_proto_gre are loaded, any GRE packet is INVALID.
>
> When nf_conntrack_proto_gre or nf_conntrack_pptp are loaded, there is no
> difference with 3.2.x.
>
> The bottom line is : if you use PPTP and conntrack with any kernel
> version, load nf_conntrack_pptp (it will load nf_conntrack_proto_gre
> automatically) and accept GRE packets in the ESTABLISHED,RELATED states.
>
>>> Is there some kind of mechanism to automatically load the extension
>>> modules before initiating the connection and unloading them after the
>>> connection has finished?
>
> None that I know of.
>
>> the way I understand the change is:
>> you need to add an according iptables rule for the first state NEW
>> packet, which will then load the according conntrack helper
>> automatically. So further packets are classified as ESTABLISHED or RELATED.
>
> Huh ?
> The NEW state is not needed if the required modules are loaded. Also, I
> don't think that a packet can trigger a module to be loaded.

Even if the modules are loaded, you need to allow the first gre packet 
as you pointed out above.

I was wrong with the module loading. I meant the rule (not the packet) 
will trigger the loading of the module, like if you write a nat table 
rule will load the iptable_nat module. I wrote this from what I thought 
to remember from reading the thread months ago, without actually testing 
it. Sorry for that.

Best regards

Mart
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  parent reply	other threads:[~2015-01-23 23:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19 13:04 conntrack GRE behaves differently in 3.17 / 3.18 Jan Niggemann
2015-01-21  2:01 ` Eliezer Croitoru
2015-01-21 13:19   ` Jan Niggemann
2015-01-21 14:33     ` Mart Frauenlob
2015-01-21 19:03       ` Jan Niggemann
2015-01-21 23:21         ` Pascal Hambourg
2015-01-22  7:55           ` Jan Niggemann
2015-01-22 10:10             ` Mart Frauenlob
2015-01-22 15:40               ` Eliezer Croitoru
2015-01-22 18:51                 ` Neal Murphy
2015-01-22 20:33               ` Pascal Hambourg
2015-01-22 21:51                 ` Jan Niggemann
2015-01-22 22:28                   ` Neal Murphy
2015-01-23 23:20                 ` Mart Frauenlob [this message]
2015-01-24  7:44                   ` Jan Niggemann
2015-01-24 15:28                     ` Mart Frauenlob
2015-01-24 20:07                       ` Pascal Hambourg
     [not found] <1430142363.3948.12.camel@alum.wpi.edu>
2015-04-27 13:47 ` Lubomir Rintel

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=54C2D74F.6040800@chello.at \
    --to=mart.frauenlob@chello.at \
    --cc=jn@hz6.de \
    --cc=netfilter@vger.kernel.org \
    --cc=pascal@plouf.fr.eu.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.