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