From: Chris Brenton <cbrenton@chrisbrenton.org>
To: manikandan@manikandan.org
Cc: netfilter <netfilter@lists.netfilter.org>
Subject: Re: ACK,RST getting dropped in the firewall.
Date: Wed, 23 Jun 2004 07:32:37 -0400 [thread overview]
Message-ID: <1087990356.2064.47.camel@grendel> (raw)
In-Reply-To: <GHEILNONPACCGBGKBEKKKEAMCHAA.manikandan@manikandan.org>
On Wed, 2004-06-23 at 07:06, Manikandan wrote:
>
> Jun 23 16:42:43 javagreen kernel: New not syn:IN=eth0 OUT=
> MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=202.138.101.5
> DST=202.138.22.218 LEN=1500 TOS=0x00 PREC=0x00 TTL=122 ID=51601 DF PROTO=TCP
> SPT=80 DPT=2162 WINDOW=64574 RES=0x00 ACK URGP=0
> Jun 23 16:42:43 javagreen kernel: New not syn:IN=eth0 OUT=
> MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=202.138.101.5
> DST=202.138.22.218 LEN=1500 TOS=0x00 PREC=0x00 TTL=122 ID=51601 DF PROTO=TCP
> SPT=80 DPT=2162 WINDOW=64574 RES=0x00 ACK URGP=0
Seen this a lot. When ever I record a trace it ends up being the
following:
Three packet handshake is normal
Established state goes normally
Client issues a FIN/ACK
State table time-out drops to 2 minutes
Server still has data to send so continues to ACK
State table time-out expires
Server gets blocked at ACK or FIN/ACK stage, session never finishes
There is obviously data getting blocked (based on the packet size) but
I've never had a user complaint.
> Jun 23 16:43:22 javagreen kernel: IPT INPUT packet died: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:0d:60:40:99:db:08:00 SRC=0.0.0.0 DST=255.255.22.255
> LEN=340 TOS=0x00 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=320
You are blocking bootp/DHCP traffic. Should not be a big deal.
> Jun 23 16:43:26 javagreen kernel: IPT INPUT packet died: IN=eth0 OUT=
> MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=4.78.20.2
> DST=202.138.22.218 LEN=84 TOS=0x00 PREC=0x00 TTL=41 ID=0 DF PROTO=ICMP
> TYPE=8 CODE=0 ID=58217 SEQ=55219
> Jun 23 16:43:26 javagreen kernel: IPT INPUT packet died: IN=eth0 OUT=
> MAC=00:09:6b:19:b4:24:00:0e:83:f6:19:9f:08:00 SRC=166.90.213.130
> DST=202.138.22.218 LEN=84 TOS=0x00 PREC=0x00 TTL=41 ID=0 DF PROTO=ICMP
> TYPE=8 CODE=0 ID=8475 SEQ=60480
You are blocking inbound Ping attempts. Nothing wrong with that. :)
HTH,
Chris
next prev parent reply other threads:[~2004-06-23 11:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-23 11:06 ACK,RST getting dropped in the firewall Manikandan
2004-06-23 11:32 ` Chris Brenton [this message]
2004-06-24 9:37 ` Gavin Hamill
2004-06-24 10:44 ` Antony Stone
2004-06-24 13:36 ` Chris Brenton
2004-06-24 13:52 ` Jozsef Kadlecsik
2004-06-24 13:54 ` Antony Stone
2004-06-24 15:48 ` Chris Brenton
2004-06-24 16:09 ` Antony Stone
2004-06-24 18:29 ` Chris Brenton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1087990356.2064.47.camel@grendel \
--to=cbrenton@chrisbrenton.org \
--cc=manikandan@manikandan.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox