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