Dropped packets logged which should be accepted by Conntrack

Dropped packets logged which should be accepted by Conntrack

[John A. Sullivan III]

Hello, all.  I find myself perplexed by what I often see in our logs.
At the end of our FORWARD chain, we log drops for no matches:

[root@fw01 log]# iptables -v -n -L FORWARD
Chain FORWARD (policy DROP 528K packets, 85M bytes)
 pkts bytes target     prot opt in     out     source
destination
  16M  925M TCPMSS     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
2284M 1690G ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0           state RELATED,ESTABLISHED
7890K  594M VPN_ALLOW  all  --  *      *       0.0.0.0/0
0.0.0.0/0           MARK match 0xcccc/0xcccc
  27M 2609M UPEPIN_DENY  all  --  *      *       0.0.0.0/0
0.0.0.0/0
  27M 2609M UPEPIN     all  --  *      *       0.0.0.0/0
0.0.0.0/0
 528K   85M LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0           LOG flags 0 level 4 prefix `No Match: '

However, my logs are always showing these drops for packets I know
should be matched in conntrack:

Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=194.187.105.194 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=48910 DF
PROTO=TCP SPT=25 DPT=60261 WINDOW=4
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=55912 WINDOW=0 RES=0
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=115.68.20.245 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=63654 DF PROTO=TCP
SPT=25 DPT=35100 WINDOW=46
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=89.31.145.16 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=58184 DF PROTO=TCP
SPT=25 DPT=6654 WINDOW=46 RE
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=206.71.61.68 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=48619 DF PROTO=TCP
SPT=25 DPT=2643 WINDOW=5840
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34623 WINDOW=0 RES=0
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34658 WINDOW=0 RES=0
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34684 WINDOW=0 RES=0
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=11211 DPT=46880 WINDOW=0 RES
Nov 14 18:45:51 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34666 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34657 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34667 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34636 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34658 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=64.34.234.107 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=8764 DF PROTO=TCP
SPT=25 DPT=48135 WINDOW=46 R
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34684 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond1 OUT=bond4 SRC=172.x.z.73
DST=172.x.y.34 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP
SPT=389 DPT=34666 WINDOW=0 RES=0
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=94.23.2.185 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=16465 DF PROTO=TCP
SPT=25 DPT=55897 WINDOW=46 RE
Nov 14 18:45:52 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
DST=89.31.145.16 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=58185 DF PROTO=TCP
SPT=25 DPT=6654 WINDOW=46 RE

The above shows SMTP, LDAP, and memcached replies which should have been
accepted.  Why would I see this?

I thought that the conntrack table might be overrun since there is a
very large rule set.  However,

[root@fw01 log]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
534
[root@fw01 log]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536
[root@fw01 log]# cat /sys/module/nf_conntrack/parameters/hashsize
16384

So it looks like we are nowhere near the max number of conntrack
entries.  So, if conntrack is not overrun, why is it not matching these
packets? Thanks - John

Re: Dropped packets logged which should be accepted by Conntrack

[Gáspár Lajos]

Hi John,

2011-11-15 04:07 keltezéssel, John A. Sullivan III írta:
> Hello, all.  I find myself perplexed by what I often see in our logs.
> At the end of our FORWARD chain, we log drops for no matches:
>
> [root@fw01 log]# iptables -v -n -L FORWARD
> Chain FORWARD (policy DROP 528K packets, 85M bytes)
>   pkts bytes target     prot opt in     out     source
> destination
>    16M  925M TCPMSS     tcp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
> 2284M 1690G ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           state RELATED,ESTABLISHED
> 7890K  594M VPN_ALLOW  all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           MARK match 0xcccc/0xcccc
>    27M 2609M UPEPIN_DENY  all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>    27M 2609M UPEPIN     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>   528K   85M LOG        all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           LOG flags 0 level 4 prefix `No Match: '
>

> The above shows SMTP, LDAP, and memcached replies which should have been
> accepted.  Why would I see this?

I do not know what kind of rules do you have between the 
"RELATED,ESTABLISHED" and the "LOG/DROP" rules, but I do not see any 
"conntrak NEW" rule there...
And as far as I can tell, your UPEPIN_DENY chain does not get any hit... 
(If that chain ment to deny any unwanted traffic.)

To answer your question:
You see those logs becaus the packets are:
  - not "RELATED" or "ESTABLISHED",
  - not filtered in the VPN_ALLOW chain, (not marked with 0xcccc)
  - not droped in the UPEPIN_DENY chain,
  - not accepter the UPEPIN chain...

These packets can be:
  a, "NEW'",
  b, "INVALID",
  c, "UNTRACKED",
  and none of them are "ACCEPT"-ed... :D

Swifty

Re: Dropped packets logged which should be accepted by Conntrack

[John A. Sullivan III]

On Tue, 2011-11-15 at 10:47 +0100, Gáspár Lajos wrote:
> Hi John,
> 
> 2011-11-15 04:07 keltezéssel, John A. Sullivan III írta:
> > Hello, all.  I find myself perplexed by what I often see in our logs.
> > At the end of our FORWARD chain, we log drops for no matches:
> >
> > [root@fw01 log]# iptables -v -n -L FORWARD
> > Chain FORWARD (policy DROP 528K packets, 85M bytes)
> >   pkts bytes target     prot opt in     out     source
> > destination
> >    16M  925M TCPMSS     tcp  --  *      *       0.0.0.0/0
> > 0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
> > 2284M 1690G ACCEPT     all  --  *      *       0.0.0.0/0
> > 0.0.0.0/0           state RELATED,ESTABLISHED
> > 7890K  594M VPN_ALLOW  all  --  *      *       0.0.0.0/0
> > 0.0.0.0/0           MARK match 0xcccc/0xcccc
> >    27M 2609M UPEPIN_DENY  all  --  *      *       0.0.0.0/0
> > 0.0.0.0/0
> >    27M 2609M UPEPIN     all  --  *      *       0.0.0.0/0
> > 0.0.0.0/0
> >   528K   85M LOG        all  --  *      *       0.0.0.0/0
> > 0.0.0.0/0           LOG flags 0 level 4 prefix `No Match: '
> >
> 
> > The above shows SMTP, LDAP, and memcached replies which should have been
> > accepted.  Why would I see this?
> 
> I do not know what kind of rules do you have between the 
> "RELATED,ESTABLISHED" and the "LOG/DROP" rules, but I do not see any 
> "conntrak NEW" rule there...
> And as far as I can tell, your UPEPIN_DENY chain does not get any hit... 
> (If that chain ment to deny any unwanted traffic.)
> 
> To answer your question:
> You see those logs becaus the packets are:
>   - not "RELATED" or "ESTABLISHED",
>   - not filtered in the VPN_ALLOW chain, (not marked with 0xcccc)
>   - not droped in the UPEPIN_DENY chain,
>   - not accepter the UPEPIN chain...
> 
> These packets can be:
>   a, "NEW'",
>   b, "INVALID",
>   c, "UNTRACKED",
>   and none of them are "ACCEPT"-ed... :D
> 
> Swifty
Thank you, Gaspar.  This is actually a fairly complicated rule set with
probably tens of thousands of rules nested in those groups based upon
the concept of firepiping rather than firewalling - the next stage of
the ISCS project (http://iscs.sourceforge.net - sorry - haven't updated
that site in years). 

Thus there are NEW -j ACCEPT rules in the path and these the original
packets to these replies match them, e.g., sending 25 /tcp to the mail
server or 389 /tcp to the LDAP server.  Note the large drop in matches
between UPEPEIN and LOG.  That's why I'm both perplexed and concerned to
see so many RELATED,ESTABLISH packets in my dropped log.

For example:
No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34 DST=94.76.241.48 LEN=107
TOS=0x00 PREC=0x00 TTL=63 ID=57617 DF PROTO=TCP SPT=25 DPT=37117

[root@fw01 log]# iptables -v -n -L UPEPIN
Chain UPEPIN (2 references)
 pkts bytes target     prot opt in     out     source               destination
  28M 2707M ProtectionFilterSource  all  --  *      *       0.0.0.0/0            0.0.0.0/0
8600K  555M ProtectionFilterTCP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6904K  527M ProtectionFilterICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  28M 2707M ACCESS_GROUPS  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain ACCESS_GROUPS (2 references)
 pkts bytes target     prot opt in     out     source               destination
  28M 2707M c1         all  --  *      *       0.0.0.0/0            0.0.0.0/0           source IP range 0.0.0.0-255.255.255.255

Chain c1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
  28M 2707M c5         all  --  *      *       0.0.0.0/0            0.0.0.0/0

[root@fw01 log]# iptables -v -n -L c5
Chain c5 (2 references)
 pkts bytes target     prot opt in     out     source               destination

66833 3692K ACCEPT     tcp  --  *      *       0.0.0.0/0            172.x.y.34         tcp dpt:25

and in the static configuration file:
-I c5 1 -d 172.x.y.34 -p 6 --dport 25 -j ACCEPT

And it works although I suspect there is a performance impact because of
the intermittent dropped packets.  Any ideas what could cause this? Or
am I misinterpreting what I am seeing.  Thanks - John

Re: Dropped packets logged which should be accepted by Conntrack

[John A. Sullivan III]

On Tue, 2011-11-15 at 10:20 -0600, Jorge Dávila wrote:
> John,
> 
> The particular thing I see in the logs is they shows the flag DF
> (Don't Fragment).
> 
> My first guess is the TCPMSS rule is the responsible for generating the logs.
> 
> Maybe adjusting the mtu for the interfaces will solve the problem.
> 
> Jorge.
<snip>
Thanks, Jorge.  However, the packets are quite small and should not be
having a problem with DF.  I thought, perhaps, they were RSTs and maybe
those were not considered RELATED but that is not always the case:

No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34 DST=187.15.198.127 LEN=117
TOS=0x00 PREC=0x00 TTL=63 ID=20811 DF PROTO=TCP SPT=25 DPT=2307
WINDOW=5840 RES=0x00 ACK PSH URGP=0

No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34 DST=180.252.147.149 LEN=55
TOS=0x00 PREC=0x00 TTL=63 ID=60912 DF PROTO=TCP SPT=25 DPT=19445
WINDOW=5840 RES=0x00 ACK PSH URGP=0

Here are two examples of packets being logged from our public SMTP
gateway with tiny packet sizes and no unusual flags.

Any other ideas, anyone, of why we would be seeing these logs when we
would suspect these packets should be ACCEPTed at the very beginning of
the FORWARD chain with a -m state --state RELATED,ESTABLISHED -j ACCEPT
rule? Thanks - John

Re: Dropped packets logged which should be accepted by Conntrack

[Jorge Dávila]

The logs are consistent with the problem of manipulating the MSS and the PMTU.

The packets are the out-of-band transmission of segments of data that
can not fit in a single tcp packet.

The TCP_NODELAY option is available beginning the Linux kernel 2.5.71.
That option forces the transmition of packet with small amount of
data.

Jorge Dávila.

El día 16 de noviembre de 2011 06:07, John A. Sullivan III
<jsullivan@opensourcedevel.com> escribió:
> On Tue, 2011-11-15 at 10:20 -0600, Jorge Dávila wrote:
>> John,
>>
>> The particular thing I see in the logs is they shows the flag DF
>> (Don't Fragment).
>>
>> My first guess is the TCPMSS rule is the responsible for generating the logs.
>>
>> Maybe adjusting the mtu for the interfaces will solve the problem.
>>
>> Jorge.
> <snip>
> Thanks, Jorge.  However, the packets are quite small and should not be
> having a problem with DF.  I thought, perhaps, they were RSTs and maybe
> those were not considered RELATED but that is not always the case:
>
> No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34 DST=187.15.198.127 LEN=117
> TOS=0x00 PREC=0x00 TTL=63 ID=20811 DF PROTO=TCP SPT=25 DPT=2307
> WINDOW=5840 RES=0x00 ACK PSH URGP=0
>
> No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34 DST=180.252.147.149 LEN=55
> TOS=0x00 PREC=0x00 TTL=63 ID=60912 DF PROTO=TCP SPT=25 DPT=19445
> WINDOW=5840 RES=0x00 ACK PSH URGP=0
>
> Here are two examples of packets being logged from our public SMTP
> gateway with tiny packet sizes and no unusual flags.
>
> Any other ideas, anyone, of why we would be seeing these logs when we
> would suspect these packets should be ACCEPTed at the very beginning of
> the FORWARD chain with a -m state --state RELATED,ESTABLISHED -j ACCEPT
> rule? Thanks - John
>
>



-- 
Jorge Isaac Dávila López
+505 8430 5462
jorgedavilalopez@gmail.com
---

Re: Dropped packets logged which should be accepted by Conntrack

[Jan Engelhardt]

On Tuesday 2011-11-15 04:07, John A. Sullivan III wrote:

>Hello, all.  I find myself perplexed by what I often see in our logs.
>At the end of our FORWARD chain, we log drops for no matches:
>
>[root@fw01 log]# iptables -v -n -L FORWARD
>Chain FORWARD (policy DROP 528K packets, 85M bytes)
> pkts bytes target     prot opt in     out     source
>destination
>  16M  925M TCPMSS     tcp  --  *      *       0.0.0.0/0
>0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
>2284M 1690G ACCEPT     all  --  *      *       0.0.0.0/0
>0.0.0.0/0           state RELATED,ESTABLISHED
>7890K  594M VPN_ALLOW  all  --  *      *       0.0.0.0/0
>0.0.0.0/0           MARK match 0xcccc/0xcccc
>  27M 2609M UPEPIN_DENY  all  --  *      *       0.0.0.0/0
>0.0.0.0/0
>  27M 2609M UPEPIN     all  --  *      *       0.0.0.0/0
>0.0.0.0/0
> 528K   85M LOG        all  --  *      *       0.0.0.0/0
>0.0.0.0/0           LOG flags 0 level 4 prefix `No Match: '
>
>However, my logs are always showing these drops for packets I know
>should be matched in conntrack:
>
>Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
>DST=194.187.105.194 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=48910 DF
>PROTO=TCP SPT=25 DPT=60261 WINDOW=4

As always, post the *full* ruleset, and do so by using iptables-save. Do 
*NOT* use -L.
The use of TCPMSS is generally not needed either - if you do, you are 
likely to be wrongly blocking ICMP.

Re: Dropped packets logged which should be accepted by Conntrack

[John A. Sullivan III]

On Wed, 2011-11-16 at 16:51 +0100, Jan Engelhardt wrote:
> On Tuesday 2011-11-15 04:07, John A. Sullivan III wrote:
> 
> >Hello, all.  I find myself perplexed by what I often see in our logs.
> >At the end of our FORWARD chain, we log drops for no matches:
> >
> >[root@fw01 log]# iptables -v -n -L FORWARD
> >Chain FORWARD (policy DROP 528K packets, 85M bytes)
> > pkts bytes target     prot opt in     out     source
> >destination
> >  16M  925M TCPMSS     tcp  --  *      *       0.0.0.0/0
> >0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
> >2284M 1690G ACCEPT     all  --  *      *       0.0.0.0/0
> >0.0.0.0/0           state RELATED,ESTABLISHED
> >7890K  594M VPN_ALLOW  all  --  *      *       0.0.0.0/0
> >0.0.0.0/0           MARK match 0xcccc/0xcccc
> >  27M 2609M UPEPIN_DENY  all  --  *      *       0.0.0.0/0
> >0.0.0.0/0
> >  27M 2609M UPEPIN     all  --  *      *       0.0.0.0/0
> >0.0.0.0/0
> > 528K   85M LOG        all  --  *      *       0.0.0.0/0
> >0.0.0.0/0           LOG flags 0 level 4 prefix `No Match: '
> >
> >However, my logs are always showing these drops for packets I know
> >should be matched in conntrack:
> >
> >Nov 14 18:45:51 fw01 kernel: No Match: IN=bond4 OUT=bond3 SRC=172.x.y.34
> >DST=194.187.105.194 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=48910 DF
> >PROTO=TCP SPT=25 DPT=60261 WINDOW=4
> 
> As always, post the *full* ruleset, and do so by using iptables-save. Do 
> *NOT* use -L.
> The use of TCPMSS is generally not needed either - if you do, you are 
> likely to be wrongly blocking ICMP.

<grin> I don't think you want me posting all of my 2000 or so rules.
Here are pertinent ones from the configuration files rather than a
listing:

*filter
:INPUT DROP
:OUTPUT DROP
:FORWARD DROP
-N ACCESS_GROUPS
-N ACCESS_GROUPS_DENY
-N VPN_ALLOW
-N ProtectionFilterTCP
-N ProtectionFilterICMP
-N ProtectionFilterBadTCP
-N ProtectionFilterSource
-N ProtectionFilterBadSource
-N UPEPIN
-N UPEPIN_DENY
-N c1
.
.
.
-N c5
COMMIT

*filter
-A UPEPIN -j ProtectionFilterSource
-A UPEPIN -p 6 -j ProtectionFilterTCP
-A UPEPIN -p 1 -j ProtectionFilterICMP
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT


*filter
-I c5 1 -d 172.x.y.34 -p 6 --dport 25 -j ACCEPT
-I c1 1 -j c5
COMMIT

*filter
-A ACCESS_GROUPS -m iprange --src-range 0.0.0.0-255.255.255.255 -j c1
-A FORWARD -m mark --mark 0xcccc/0xcccc -j VPN_ALLOW
-A UPEPIN_DENY -j ACCESS_GROUPS_DENY
-A UPEPIN -j ACCESS_GROUPS
-A INPUT -j UPEPIN_DENY
-A INPUT -j UPEPIN
-A FORWARD -j UPEPIN_DENY
-A FORWARD -j UPEPIN
-A FORWARD -j LOG --log-level warning --log-prefix "No Match: "
-A INPUT -j LOG --log-level warning --log-prefix "No Match: "
COMMIT

I may be ignorant on this matter (and hence this request for help) but
has the Internet matured to the point that the TCPMSS rule is no longer
necessary? Is everyone now handling requests for fragmentation properly?
It has been a number of years since we created that rule.

However, if only applies to packets with SYN set and RST unset and then
only changes the mss.  Are we saying that changing that value
invalidates the conntrack match? I didn't think conntrack evaluated that
portion of the packet.  I don't think these are fragments as Jorge has
suggested as these are SYN,ACK packets and thus should be tiny to begin
with.  So I'm not sure why TCPMSS would cause this issue.  Thanks - John

Re: Dropped packets logged which should be accepted by Conntrack

[Jan Engelhardt]

On Wednesday 2011-11-16 20:25, John A. Sullivan III wrote:

>:FORWARD DROP
>-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
>-A FORWARD -m mark --mark 0xcccc/0xcccc -j VPN_ALLOW
>-A FORWARD -j UPEPIN_DENY
>-A FORWARD -j UPEPIN
>-A FORWARD -j LOG --log-level warning --log-prefix "No Match: "
>
>I may be ignorant on this matter (and hence this request for help) but
>has the Internet matured to the point that the TCPMSS rule is no longer
>necessary? Is everyone now handling requests for fragmentation properly?

Well, of course there's always some "who never grow up", but I have not 
seen any such sites lately. Probably because such pages are of such a 
sort that does not interest me ;-)