* Dropped packets logged which should be accepted by Conntrack @ 2011-11-15 3:07 John A. Sullivan III 2011-11-15 9:47 ` Gáspár Lajos 2011-11-16 15:51 ` Jan Engelhardt 0 siblings, 2 replies; 8+ messages in thread From: John A. Sullivan III @ 2011-11-15 3:07 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-15 3:07 Dropped packets logged which should be accepted by Conntrack John A. Sullivan III @ 2011-11-15 9:47 ` Gáspár Lajos 2011-11-15 12:57 ` John A. Sullivan III 2011-11-16 15:51 ` Jan Engelhardt 1 sibling, 1 reply; 8+ messages in thread From: Gáspár Lajos @ 2011-11-15 9:47 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-15 9:47 ` Gáspár Lajos @ 2011-11-15 12:57 ` John A. Sullivan III [not found] ` <CAG61UF-BmX38MbC=5MUsBkWD3Fixx7-=AENxHKtbRi9TX7NzmA@mail.gmail.com> 0 siblings, 1 reply; 8+ messages in thread From: John A. Sullivan III @ 2011-11-15 12:57 UTC (permalink / raw) To: Gáspár Lajos; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CAG61UF-BmX38MbC=5MUsBkWD3Fixx7-=AENxHKtbRi9TX7NzmA@mail.gmail.com>]
* Re: Dropped packets logged which should be accepted by Conntrack [not found] ` <CAG61UF-BmX38MbC=5MUsBkWD3Fixx7-=AENxHKtbRi9TX7NzmA@mail.gmail.com> @ 2011-11-16 12:07 ` John A. Sullivan III 2011-11-16 15:20 ` Jorge Dávila 0 siblings, 1 reply; 8+ messages in thread From: John A. Sullivan III @ 2011-11-16 12:07 UTC (permalink / raw) To: Jorge Dávila; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-16 12:07 ` John A. Sullivan III @ 2011-11-16 15:20 ` Jorge Dávila 0 siblings, 0 replies; 8+ messages in thread From: Jorge Dávila @ 2011-11-16 15:20 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netfilter 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 --- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-15 3:07 Dropped packets logged which should be accepted by Conntrack John A. Sullivan III 2011-11-15 9:47 ` Gáspár Lajos @ 2011-11-16 15:51 ` Jan Engelhardt 2011-11-16 19:25 ` John A. Sullivan III 1 sibling, 1 reply; 8+ messages in thread From: Jan Engelhardt @ 2011-11-16 15:51 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netfilter 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-16 15:51 ` Jan Engelhardt @ 2011-11-16 19:25 ` John A. Sullivan III 2011-12-04 16:21 ` Jan Engelhardt 0 siblings, 1 reply; 8+ messages in thread From: John A. Sullivan III @ 2011-11-16 19:25 UTC (permalink / raw) To: Jan Engelhardt; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dropped packets logged which should be accepted by Conntrack 2011-11-16 19:25 ` John A. Sullivan III @ 2011-12-04 16:21 ` Jan Engelhardt 0 siblings, 0 replies; 8+ messages in thread From: Jan Engelhardt @ 2011-12-04 16:21 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netfilter 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 ;-) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-12-04 16:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-15 3:07 Dropped packets logged which should be accepted by Conntrack John A. Sullivan III
2011-11-15 9:47 ` Gáspár Lajos
2011-11-15 12:57 ` John A. Sullivan III
[not found] ` <CAG61UF-BmX38MbC=5MUsBkWD3Fixx7-=AENxHKtbRi9TX7NzmA@mail.gmail.com>
2011-11-16 12:07 ` John A. Sullivan III
2011-11-16 15:20 ` Jorge Dávila
2011-11-16 15:51 ` Jan Engelhardt
2011-11-16 19:25 ` John A. Sullivan III
2011-12-04 16:21 ` Jan Engelhardt
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.