iptables v1.2.4 logs dropped packets that should have been allowed ???

Discussion in 'Linux Networking' started by Tom Van Overbeke, Jul 16, 2003.

  1. Hi,


    I hope someone can shed some light on a mistery i have:


    our firewall (also squid proxy) serves some 50 desktops for web browsing.

    Everything works fine, noone complains about sites not being accessible or
    sth, but in the firewall logs, i see very regularly 2 types of blocked
    packets:


    Jul 16 16:49:11 dobermann kernel: -drop_the_rest-IN=eth0 OUT=
    MAC=00:06:5b:f7:66:96:00:00:d1:ec:fa:3b:08:00 SRC=213.199.148.12
    DST=172.17.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=11706 PROTO=TCP SPT=80
    DPT=55475 WINDOW=17125 RES=0x00 ACK URGP=0

    DST ip is the external interface of the proxy server. to me, this appears to
    be the reply from an attempt of the squid proxy to initiate a connection
    with a remote website (because of the ACK).
    i see no reason why this packet would be blocked, because i can't find the
    corresponding SYN packet in my logs.
    anyway, The connection between these hosts and ports in this example are
    configured to be permitted.


    second type of blocked packets:

    Jul 16 11:57:47 dobermann kernel: -drop_the_rest-IN= OUT=eth1 SRC=172.21.3.1
    DST=172.21.3.209 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=6144 PROTO=TCP SPT=3128
    DPT=2408 WINDOW=16056 RES=0x00 ACK PSH FIN URGP=0
    Jul 16 13:16:19 dobermann kernel: -drop_the_rest-IN= OUT=eth1 SRC=172.21.3.1
    DST=172.21.3.209 LEN=1102 TOS=0x00 PREC=0x00 TTL=64 ID=25203 PROTO=TCP
    SPT=3128 DPT=3384 WINDOW=6468 RES=0x00 ACK PSH URGP=0

    SRC is the internal ip of the firewall / squid proxy; DST is one of the
    desktop pc's used to surf the web.

    this packet looks like it's the squid that is forwarding the received web
    page back to the requesting client (because of the ACK and PSH bits set).
    the source port is 3128, where we have configured our proxy to listen to.


    to me this doesn't make sence: it seems almost like iptables has forgotten
    about the already established connection and seems to drop the packet
    because it can't find it in the connection tracking table.

    our firewall is iptables v1.2.4 running on redhat advanced server 2.1.
    the firewall was setup via fwbuilder, with connection tracking enabled for
    most of the rules (and definitely for the 'allow squid traffic' rule).
    cat /proc/sys/net/ipv4/conntrack_max is 32760
    cat /proc/net/ip_conntrack | wc -l is 172 (i assume these 2 variables are
    related ?).



    thx,


    Tom.
     
    Tom Van Overbeke, Jul 16, 2003
    #1
    1. Advertisements

  2. It's possible that the connections are already closed.
    The packets being dropped are probably retransmissions of earlier
    packets that made it through.
    You would need to capture a whole session to diagnose it properly.
    In the meantime, nobody's complaining about dropped connections, right?
     
    Allen Kistler, Jul 18, 2003
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.