conntrack GRE behaves differently in 3.17 / 3.18

conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Hi list,

espite using the same pptp-client config and the same firewall rules, 
3.18 behaves differently than 3.17 in that I can't connect to a certain 
VPN using 3.18. Logging with tcpdump shows that in 3.18, GRE packets 
sent by the server are dropped while in 3.17 they are not. Testing 
further, I found rule #2 from INPUT to be the issue, leading me to think 
that a change in connection tracking may be the cause.

May this be an intended change in behaviour or a bug?
How may I assist in tracking that down (and eventually fixing it)?

Machine
Lenovo T400, Debian 7.8

Iptables (no NAT involved)
Chain INPUT (policy DROP 2 packets, 120 bytes)
  pkts bytes target     prot opt in     out     source               
destination
     0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            
0.0.0.0/0
     8   984 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            ctstate RELATED,ESTABLISHED
     0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            
0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               
destination

Chain OUTPUT (policy ACCEPT 8 packets, 2292 bytes)
  pkts bytes target     prot opt in     out     source               
destination


Kernel configs:
3.17: https://gist.github.com/2974aa489986d6fc26e3
3.18: https://gist.github.com/2dc04e2ea55bde3360fe

Cheers
jan

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Eliezer Croitoru]

On 19/01/2015 15:04, Jan Niggemann wrote:
> Machine
> Lenovo T400, Debian 7.8

As in a desktop?
Can you show the lsmod output?
I am not quite sure how the INPUT should be related directly to the GRE 
since the origin of the GRE(if I remember right) is from the client side 
and not the server side.

Eliezer

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Hi Eliezer and others,

Zitat von Eliezer Croitoru <eliezer@ngtech.co.il>:
> On 19/01/2015 15:04, Jan Niggemann wrote:
>> Machine
>> Lenovo T400, Debian 7.8
>
> As in a desktop?
> Can you show the lsmod output?
> I am not quite sure how the INPUT should be related directly to the  
> GRE since the origin of the GRE(if I remember right) is from the  
> client side and not the server side.
that's correct. The pptp devs have checked my pptp debug log and told  
me to check for lost GRE packets.
Further testing with tcpdump shows that my pptp client is sending GRE  
packets TO the server and receiving GRE packets FROM the server.
The issue is that using 3.18, the servers' GRE packets are dropped by  
the aforementioned rule (rule #2 below), while in 3.17 they are not.

Chain INPUT (policy DROP 2 packets, 120 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
8 984 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

After manually inserting a rule to explicitly permit GRE (iptables -I  
INPUT 2 -p gre -j ACCEPT) before rule #2, the VPN connection works,  
because the pptp client now gets the servers' GRE packets.

I (perhaps wrongly?) assume that if it's the rule "[...] ctstate  
RELATED,ESTABLISHED" that drops the servers' GRE packets with kernel  
3.18, then the connection tracking has somehow changed between 3.17  
and 3.18.

Jan

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Mart Frauenlob]

On 21.01.2015 14:19, Jan Niggemann wrote:
> Hi Eliezer and others,
>
> Zitat von Eliezer Croitoru <eliezer@ngtech.co.il>:
>> On 19/01/2015 15:04, Jan Niggemann wrote:
>>> Machine
>>> Lenovo T400, Debian 7.8
>>
>> As in a desktop?
>> Can you show the lsmod output?
>> I am not quite sure how the INPUT should be related directly to the
>> GRE since the origin of the GRE(if I remember right) is from the
>> client side and not the server side.
> that's correct. The pptp devs have checked my pptp debug log and told me
> to check for lost GRE packets.
> Further testing with tcpdump shows that my pptp client is sending GRE
> packets TO the server and receiving GRE packets FROM the server.
> The issue is that using 3.18, the servers' GRE packets are dropped by
> the aforementioned rule (rule #2 below), while in 3.17 they are not.
>
> Chain INPUT (policy DROP 2 packets, 120 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 8 984 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
>
> After manually inserting a rule to explicitly permit GRE (iptables -I
> INPUT 2 -p gre -j ACCEPT) before rule #2, the VPN connection works,
> because the pptp client now gets the servers' GRE packets.
>
> I (perhaps wrongly?) assume that if it's the rule "[...] ctstate
> RELATED,ESTABLISHED" that drops the servers' GRE packets with kernel
> 3.18, then the connection tracking has somehow changed between 3.17 and
> 3.18.
>
> Jan

Hello,

please always use the output of iptables -S.

This might be the reason:
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54397/focus=54426

/lib/modules/$(uname -r)/kernel/net/netfilter/nf_conntrack_proto_gre.ko
is available as specific helper.

Best regards
Mart

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Zitat von Mart Frauenlob <mart.frauenlob@chello.at>:
> /lib/modules/$(uname -r)/kernel/net/netfilter/nf_conntrack_proto_gre.ko
> is available as specific helper.

GRE packets are still dropped, even after "modprobe nf_conntrack_proto_gre".
Isn't that how it's supposed to work, or am I still missing something?

root@laptop:/etc# iptables -S;lsmod|grep conntrack
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
nf_conntrack_proto_gre    12886  0
nf_conntrack_ipv4      18003  1
nf_defrag_ipv4         12443  1 nf_conntrack_ipv4
xt_conntrack           12601  1
nf_conntrack           57737  3  
nf_conntrack_proto_gre,xt_conntrack,nf_conntrack_ipv4
x_tables               18078  5  
ip_tables,xt_tcpudp,xt_conntrack,iptable_filter,iptable_mangle

Jan

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Pascal Hambourg]

Jan Niggemann a écrit :
> 
> nf_conntrack_proto_gre    12886  0
> nf_conntrack_ipv4      18003  1
> nf_defrag_ipv4         12443  1 nf_conntrack_ipv4
> xt_conntrack           12601  1
> nf_conntrack           57737  3  
> nf_conntrack_proto_gre,xt_conntrack,nf_conntrack_ipv4
> x_tables               18078  5  
> ip_tables,xt_tcpudp,xt_conntrack,iptable_filter,iptable_mangle

I do not see nf_conntrack_pptp here. It is required so that the first
GRE packet has the RELATED state.

Note : IIRC IME, the first GRE packet in a PPTP connection may be sent
by either side, client or server. GRE is used by PPTP to transport PPP,
and PPP is a peer-to-peer protocol, not client-server.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Zitat von Pascal Hambourg <pascal@plouf.fr.eu.org>:
> Jan Niggemann a écrit :
>>
>> nf_conntrack_proto_gre    12886  0
>> nf_conntrack_ipv4      18003  1
>> nf_defrag_ipv4         12443  1 nf_conntrack_ipv4
>> xt_conntrack           12601  1
>> nf_conntrack           57737  3
>> nf_conntrack_proto_gre,xt_conntrack,nf_conntrack_ipv4
>> x_tables               18078  5
>> ip_tables,xt_tcpudp,xt_conntrack,iptable_filter,iptable_mangle
>
> 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?

Is there some kind of mechanism to automatically load the extension  
modules before initiating the connection and unloading them after the  
connection has finished?

Jan

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Mart Frauenlob]

On 22.01.2015 08:55, Jan Niggemann wrote:
> Zitat von Pascal Hambourg <pascal@plouf.fr.eu.org>:
>> Jan Niggemann a écrit :
>>>
>>> nf_conntrack_proto_gre    12886  0
>>> nf_conntrack_ipv4      18003  1
>>> nf_defrag_ipv4         12443  1 nf_conntrack_ipv4
>>> xt_conntrack           12601  1
>>> nf_conntrack           57737  3
>>> nf_conntrack_proto_gre,xt_conntrack,nf_conntrack_ipv4
>>> x_tables               18078  5
>>> ip_tables,xt_tcpudp,xt_conntrack,iptable_filter,iptable_mangle
>>
>> 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?
>
> Is there some kind of mechanism to automatically load the extension
> modules before initiating the connection and unloading them after the
> connection has finished?

Hello,

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.
There is no mechanism of unloading a module once it has been loaded afaik.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Eliezer Croitoru]

Hey,

The way iptables rules are working is "first match" so in the case of an 
ACCEPT rule it will only be ACCEPTED if it matches the rule else it will 
try the next rule.
Always there was a need to add two rules to match an ESTABLISHED,RELATED.
1 - For the NEW state
2 - For the ESTABLISHED,RELATED

As long these rules are there with an ACCEPT target it will always be fine.

The main consideration is what will be faster to match from the two?
 From what I have seen until now FW rules usually have an 
ESTABLISHED,RELATED rule first and then the other NEW rules.

If it's right to "hijack" the thread for this particular case:
Which is better to be first?

Eliezer

On 22/01/2015 12:10, Mart Frauenlob wrote:
> Hello,
>
> 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.
> There is no mechanism of unloading a module once it has been loaded afaik.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Neal Murphy]

On Thursday, January 22, 2015 10:40:20 AM Eliezer Croitoru wrote:
> Hey,
> 
> The way iptables rules are working is "first match" so in the case of an
> ACCEPT rule it will only be ACCEPTED if it matches the rule else it will
> try the next rule.
> Always there was a need to add two rules to match an ESTABLISHED,RELATED.
> 1 - For the NEW state
> 2 - For the ESTABLISHED,RELATED
> 
> As long these rules are there with an ACCEPT target it will always be fine.
> 
> The main consideration is what will be faster to match from the two?
>  From what I have seen until now FW rules usually have an
> ESTABLISHED,RELATED rule first and then the other NEW rules.
> 
> If it's right to "hijack" the thread for this particular case:
> Which is better to be first?

There are far more EST/REL packets than there are NEW. The sooner you deal 
with the former, the fewer CPU cycles you'll waste handling packets you know 
will not and cannot match rules. For example:
----
-A FORWARD -s 192.0.2.0/24 -j tndrop
-A FORWARD -d 192.0.2.0/24 -j tndrop
-A FORWARD -s 198.51.100.0/24 -j tndrop
-A FORWARD -d 198.51.100.0/24 -j tndrop
-A FORWARD -s 203.0.113.0/24 -j tndrop
-A FORWARD -d 203.0.113.0/24 -j tndrop
-A FORWARD -i ppp0 -j ipblock
-A FORWARD -i ippp0 -j ipblock
-A FORWARD -i eth3 -j ipblock
-A FORWARD -j timedaccess
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
 .
 .
 .
----
First deal with packets that are always blocked or may be blocked depending on 
the current time. REL/EST that get past that are accepted. The remainder are 
NEW and can be handled as slowly and excruciatingly as desired. Of course, you 
DROPped INVALID packets very early, in mangle:PREROUTING; it isn't worth 
wasting even one extra CPU cycle to process those since netfilter has no idea 
why it received them and has no idea what to do with them. "Thentuwion! Thwow 
it to the gwound!"

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Pascal Hambourg]

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.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Zitat von Pascal Hambourg <pascal@plouf.fr.eu.org>:
> 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.
Thank you for testing this.
I still have tons to learn, but I realized that I can use the pptp  
connection without any helper modules by explicitly ACCEPTing gre  
packets from the VPN server:
#iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s XX.XX.XX.XX/32 -p gre -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

So now I know 2 possibilities that work, either loading  
nf_conntrack_pptp or the aforementioned rule to accept gre packets.
Which of both is a "better" approach with regards to security,  
performance, ...?

jan

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Neal Murphy]

On Thursday, January 22, 2015 04:51:38 PM Jan Niggemann wrote:
> Zitat von Pascal Hambourg <pascal@plouf.fr.eu.org>:
> > 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.
> 
> Thank you for testing this.
> I still have tons to learn, but I realized that I can use the pptp
> connection without any helper modules by explicitly ACCEPTing gre
> packets from the VPN server:
> #iptables -S
> -P INPUT DROP
> -P FORWARD DROP
> -P OUTPUT ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -s XX.XX.XX.XX/32 -p gre -j ACCEPT
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
> 
> So now I know 2 possibilities that work, either loading
> nf_conntrack_pptp or the aforementioned rule to accept gre packets.
> Which of both is a "better" approach with regards to security,
> performance, ...?

[Without being thoroughly pedantic; a complete technical explanation would 
include everything the helpers do]

Using the helper is the better approach. It positively ties the related GRE 
packet 'stream' to its PPTP control conn, allowing only those that the 
validated control conn has requested. Otherwise, you would be admitting *any* 
GRE stream from the server, even those that are not 'validated'. (Worst case? 
Malware could set up a tunnel using GRE.)

The idea is the same with the FTP helper; only those data conns that are 
associated with a command from a validated control session to transfer data 
are allowed to connect. If you allowed every FTP data conn, anyone could use 
the FTP data ports to transfer data.

But it boils down to how tightly you want to control your firewall and the 
packets that traverse it. My philosophy is, "Block all incoming and outgoing 
conns except those I explicitly allow and those I implicitly allow via 
helpers." Your philosophy may differ.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Mart Frauenlob]

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
>

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Jan Niggemann]

Zitat von Mart Frauenlob <mart.frauenlob@chello.at>:
> Even if the modules are loaded, you need to allow the first gre  
> packet as you pointed out above.
At least on my system it's sufficient that I load conntrack_pptp. With  
the following rules I can then create a pptp connection:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
I do not need to explicitly allow any gre traffic for the pptp vpn to work.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Mart Frauenlob]

On 24.01.2015 08:44, Jan Niggemann wrote:
> Zitat von Mart Frauenlob <mart.frauenlob@chello.at>:
>> Even if the modules are loaded, you need to allow the first gre packet
>> as you pointed out above.
> At least on my system it's sufficient that I load conntrack_pptp. With
> the following rules I can then create a pptp connection:
> -P INPUT DROP
> -P FORWARD DROP
> -P OUTPUT ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> I do not need to explicitly allow any gre traffic for the pptp vpn to work.

Because it's accepted in the OUTPUT chain by the default policy?

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Pascal Hambourg]

Mart Frauenlob a écrit :
> On 24.01.2015 08:44, Jan Niggemann wrote:
>> At least on my system it's sufficient that I load conntrack_pptp. With
>> the following rules I can then create a pptp connection:
>> -P INPUT DROP
>> -P FORWARD DROP
>> -P OUTPUT ACCEPT
>> -A INPUT -i lo -j ACCEPT
>> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
>> I do not need to explicitly allow any gre traffic for the pptp vpn to work.
> 
> Because it's accepted in the OUTPUT chain by the default policy?

AND because nf_conntrack_pptp classifies incoming GRE packets as RELATED
or ESTABLISHED, so they are accepted by the conntrack rule.

Re: conntrack GRE behaves differently in 3.17 / 3.18

[Lubomir Rintel]

On Thu, 2015-01-22 at 18:51 +0000, Neal Murphy wrote:
> On Thursday, January 22, 2015 10:40:20 AM Eliezer Croitoru wrote:
...
> > 
> First deal with packets that are always blocked or may be blocked depending on 
> the current time. REL/EST that get past that are accepted. The remainder are 
> NEW and can be handled as slowly and excruciatingly as desired. Of course, you 
> DROPped INVALID packets very early, in mangle:PREROUTING; it isn't worth 
> wasting even one extra CPU cycle to process those since netfilter has no idea 
> why it received them and has no idea what to do with them. "Thentuwion! Thwow 
> it to the gwound!"

Ah, about eleven, sir!

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