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@xxxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
