I am seeing messages such as:
Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
URGP=0
In my firewall logs. I see them for ACK RST as well. These are valid
connections. My rules follow for the most part (a few allowed
connections to the machine in question have been removed from the
list). This often leaves open connections in a half closed state on
machines behind this firewall. It also some times kills totally open
connections and I see packets rejected that should be allowed through.
Please, help me help. Also, please CC me. The account I am subscribed
to the list with is acting up and I may be killing it.
Chain INPUT (policy DROP 3 packets, 999 bytes)
pkts bytes target prot opt in out source
destination
30 2880 DROP udp -- any any anywhere
anywhere udp spt:netbios-ns
33 7607 DROP udp -- any any anywhere
anywhere udp spt:netbios-dgm
37 3680 ICMP_INPUT icmp -- any any anywhere
anywhere
16543 5783K tcprules all -- any any anywhere
anywhere
0 0 firewall all -- any any anywhere
anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
1485 280K tcprules all -- any any anywhere
anywhere
0 0 firewall all -- any any anywhere
anywhere
Chain OUTPUT (policy ACCEPT 17692 packets, 6181610 bytes)
pkts bytes target prot opt in out source
destination
Chain ICMP_INPUT (1 references)
pkts bytes target prot opt in out source
destination
26 2184 ACCEPT icmp -- !ppp+ any anywhere
anywhere icmp echo-request
0 0 ACCEPT icmp -- any any anywhere
anywhere icmp echo-reply
11 1496 ACCEPT icmp -- any any anywhere
anywhere icmp destination-unreachable
0 0 LOGACCEPT icmp -- any any anywhere
anywhere icmp source-quench
0 0 LOGACCEPT icmp -- any any anywhere
anywhere icmp time-exceeded
0 0 LOGACCEPT icmp -- any any anywhere
anywhere icmp parameter-problem
0 0 LOGACCEPT icmp -- any any anywhere
anywhere icmp timestamp-request
0 0 LOGACCEPT icmp -- any any anywhere
anywhere icmp timestamp-reply
0 0 firewall icmp -- any any anywhere
anywhere
Chain LOGACCEPT (5 references)
pkts bytes target prot opt in out source
destination
0 0 LOG all -- any any anywhere
anywhere LOG level info prefix `PACKET ACCEPTED:'
0 0 ACCEPT all -- any any anywhere
anywhere
Chain M_DEBUG (0 references)
pkts bytes target prot opt in out source
destination
Chain firewall (4 references)
pkts bytes target prot opt in out source
destination
116 18258 LOG all -- any any anywhere
anywhere LOG level info prefix `Firewall:'
116 18258 DROP all -- any any anywhere
anywhere
Chain tcprules (2 references)
pkts bytes target prot opt in out source
destination
17325 6007K ACCEPT all -- any any anywhere
anywhere state RELATED,ESTABLISHED
587 37774 ACCEPT all -- !ppp+ any anywhere
anywhere state NEW
116 18258 firewall all -- ppp+ any anywhere
anywhere state INVALID,NEW
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
On 9 Oct 2001, Trever L. Adams wrote:
> I am seeing messages such as:
>
> Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
> SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
> ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
> URGP=0
>
> In my firewall logs. I see them for ACK RST as well. These are valid
> connections. My rules follow for the most part (a few allowed
> connections to the machine in question have been removed from the
> list). This often leaves open connections in a half closed state on
> machines behind this firewall. It also some times kills totally open
> connections and I see packets rejected that should be allowed through.
I see this too. iptables is refusing packets on locally-initiated TCP
connections when the RELATED,ESTABLISHED rule should be letting them
through.
I mentioned this problem on the netfilter list but my message fell into
a black hole and was apparently beyond the horizon of the developers.
-jwb
On Tue, 2001-10-09 at 13:07, Jeffrey W. Baker wrote:
> I see this too. iptables is refusing packets on locally-initiated TCP
> connections when the RELATED,ESTABLISHED rule should be letting them
> through.
>
> I mentioned this problem on the netfilter list but my message fell into
> a black hole and was apparently beyond the horizon of the developers.
>
> -jwb
Maybe I misunderstand you, define locally-initiated. Do you mean net or
do you mean box? Mine happens on connections made by the firewall
(proxy for web) and on other connections initiated internally. We
currently only allow identd and a few others from external (identd is
spoofed more or less).
I am glad I am not the only one seeing this problem. I have the
established, related as well. The only thing that should be dropped
before it gets handled is certain ICMP messages (if someone thinks I am
dropping something I shouldn't, let me know) and windows networking
datagrams (used to keep the line up from internal machines, so I killed
it).
The big problems I have are a few websites and digitalme.com (all
services... web, mail, etc.).
Trever Adams
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
----- Original Message -----
From: "Trever L. Adams" <[email protected]>
To: "Linux Kernel Mailing List" <[email protected]>
> I am seeing messages such as:
>
> Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
> SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
> ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
> URGP=0
>
> In my firewall logs. I see them for ACK RST as well. These are valid
> connections. My rules follow for the most part (a few allowed
> connections to the machine in question have been removed from the
> list). This often leaves open connections in a half closed state on
> machines behind this firewall. It also some times kills totally open
> connections and I see packets rejected that should be allowed through.
This is someone on the outside scanning you for Back Orifice. I don't
understand why this is supposed to be a valid connection.
>From your iptables output, it looks like your rules are working properly.
(They aren't set up exactly how I would have done it, but it's all a matter
of style.)
Can you give a more specific example of something that it being DROPped when
it shouldn't be?
--Wilson.
On 9 Oct 2001, Trever L. Adams wrote:
> On Tue, 2001-10-09 at 13:07, Jeffrey W. Baker wrote:
> > I see this too. iptables is refusing packets on locally-initiated TCP
> > connections when the RELATED,ESTABLISHED rule should be letting them
> > through.
> >
> > I mentioned this problem on the netfilter list but my message fell into
> > a black hole and was apparently beyond the horizon of the developers.
> >
> > -jwb
>
> Maybe I misunderstand you, define locally-initiated. Do you mean net or
> do you mean box? Mine happens on connections made by the firewall
> (proxy for web) and on other connections initiated internally. We
> currently only allow identd and a few others from external (identd is
> spoofed more or less).
I mean connections originating from userland processes running on the
machine with iptables configured. This machine does not act as a NAT or
router for any other machine.
We make about 200000 outbound connections to web sites in a day. Of these
connections, a few thousand get fucked up by iptables (iptables suddenly
decides to drop packets on this connection).
-jwb
On Tue, 2001-10-09 at 14:31, Jeffrey W. Baker wrote:
> I mean connections originating from userland processes running on the
> machine with iptables configured. This machine does not act as a NAT or
> router for any other machine.
>
> We make about 200000 outbound connections to web sites in a day. Of these
> connections, a few thousand get fucked up by iptables (iptables suddenly
> decides to drop packets on this connection).
>
> -jwb
Mine does NAT. So it appears this is not NAT related (though it may be
further aggravated by NAT). My connection rate is FAR lower than
yours. Our total connections may be 100,000 on a high rate day (just a
guess... I really do not know).
Interesting.
Trever Adams
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
On Tue, 2001-10-09 at 13:40, Wilson wrote:
> This is someone on the outside scanning you for Back Orifice. I don't
> understand why this is supposed to be a valid connection.
> >From your iptables output, it looks like your rules are working properly.
> (They aren't set up exactly how I would have done it, but it's all a matter
> of style.)
> Can you give a more specific example of something that it being DROPped when
> it shouldn't be?
>
> --Wilson.
>
Sure thing. I suppose I should have chosen a connection better from the
logs. These were valid connections to digitalme.com on pop3 (I think or
is that smtp...). Happens with web connections to there and other
places as well.
Oct 9 13:27:05 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
SRC=193.97.97.75 DST=209.237.196.198 LEN=40 TOS=0x00 PREC=0x00 TTL=116
ID=6369 DF PROTO=TCP SPT=110 DPT=2213 WINDOW=0 RES=0x00 ACK RST URGP=0
Oct 9 13:31:44 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
SRC=193.97.97.75 DST=209.237.196.198 LEN=40 TOS=0x00 PREC=0x00 TTL=116
ID=13344 DF PROTO=TCP SPT=110 DPT=2220 WINDOW=0 RES=0x00 ACK RST URGP=0
Oct 9 13:39:03 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
SRC=193.97.97.75 DST=209.237.196.198 LEN=40 TOS=0x00 PREC=0x00 TTL=116
ID=26891 DF PROTO=TCP SPT=110 DPT=2251 WINDOW=0 RES=0x00 ACK RST URGP=0
Oct 9 13:47:16 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
SRC=193.97.97.75 DST=209.237.196.198 LEN=40 TOS=0x00 PREC=0x00 TTL=116
ID=41385 DF PROTO=TCP SPT=110 DPT=2254 WINDOW=0 RES=0x00 ACK RST URGP=0
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
On 9 Oct 2001, Trever L. Adams wrote:
> On Tue, 2001-10-09 at 14:31, Jeffrey W. Baker wrote:
> > I mean connections originating from userland processes running on the
> > machine with iptables configured. This machine does not act as a NAT or
> > router for any other machine.
> >
> > We make about 200000 outbound connections to web sites in a day. Of these
> > connections, a few thousand get fucked up by iptables (iptables suddenly
> > decides to drop packets on this connection).
> >
> > -jwb
>
> Mine does NAT. So it appears this is not NAT related (though it may be
> further aggravated by NAT). My connection rate is FAR lower than
> yours. Our total connections may be 100,000 on a high rate day (just a
> guess... I really do not know).
My machine has three IP addrs bound to one physical interface and uses
policy routing. Do you use any of those?
-jwb
On Tue, 2001-10-09 at 16:48, Jeffrey W. Baker wrote:
> > Mine does NAT. So it appears this is not NAT related (though it may be
> > further aggravated by NAT). My connection rate is FAR lower than
> > yours. Our total connections may be 100,000 on a high rate day (just a
> > guess... I really do not know).
>
> My machine has three IP addrs bound to one physical interface and uses
> policy routing. Do you use any of those?
>
> -jwb
Two IP addresses. One to the internal ethernet, one to the external
(dynamic ip) ppp. I do not believe I am doing policy routing. I have
the static route for ethernet and ppp sets up its own.
Trever
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
stupid question...
have you got a rule like
iptables -A INPUT -m unclean -j DROP
enabled?
On Tue, 9 Oct 2001, Jeffrey W. Baker wrote:
> On 9 Oct 2001, Trever L. Adams wrote:
>
> > On Tue, 2001-10-09 at 13:07, Jeffrey W. Baker wrote:
> > > I see this too. iptables is refusing packets on locally-initiated TCP
> > > connections when the RELATED,ESTABLISHED rule should be letting them
> > > through.
> > >
> > > I mentioned this problem on the netfilter list but my message fell into
> > > a black hole and was apparently beyond the horizon of the developers.
> > >
> > > -jwb
> >
> > Maybe I misunderstand you, define locally-initiated. Do you mean net or
> > do you mean box? Mine happens on connections made by the firewall
> > (proxy for web) and on other connections initiated internally. We
> > currently only allow identd and a few others from external (identd is
> > spoofed more or less).
>
> I mean connections originating from userland processes running on the
> machine with iptables configured. This machine does not act as a NAT or
> router for any other machine.
>
> We make about 200000 outbound connections to web sites in a day. Of these
> connections, a few thousand get fucked up by iptables (iptables suddenly
> decides to drop packets on this connection).
>
> -jwb
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 2001-10-09 at 18:46, Luigi Genoni wrote:
> stupid question...
> have you got a rule like
>
> iptables -A INPUT -m unclean -j DROP
>
> enabled?
I do not know what unclean means, so I don't know.
I have one that only accepts NEW from the inside.
I have one that accepts all ESTABLISHED,RELATED.
I have one that drops NEW,INVALID from ppp0 (outside world).
Trever
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
and what is the content of
/proc/net/ip_conntrack
file?
how big is the buffer you are using for packet tracing?
(/proc/sys/net/ipv4/ip_conntrack_max)
On 9 Oct 2001, Trever L. Adams wrote:
> On Tue, 2001-10-09 at 18:46, Luigi Genoni wrote:
> > stupid question...
> > have you got a rule like
> >
> > iptables -A INPUT -m unclean -j DROP
> >
> > enabled?
>
> I do not know what unclean means, so I don't know.
>
> I have one that only accepts NEW from the inside.
> I have one that accepts all ESTABLISHED,RELATED.
> I have one that drops NEW,INVALID from ppp0 (outside world).
>
> Trever
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
On Wed, 10 Oct 2001, Luigi Genoni wrote:
> and what is the content of
> /proc/net/ip_conntrack
> file?
>
> how big is the buffer you are using for packet tracing?
> (/proc/sys/net/ipv4/ip_conntrack_max)
Well, I'm not going to send that file to the Internet at large, but
ip_conntrack current has about 2100 lines and the max is 65535.
-jwb
So the buffer is big enought for your traffic, I suppose.
I saw something similar to your report, but indeed the buffer was too
small.
A good thing would be to see a packet dropped and the entries in
/proc/net/ip_conntrack, so that it will be possible to infer something.
with 2.4.10 i see packet tracing working very well also under
eavy network loads if the buffer is big enought...
and you are not using the controvers unclean module...
On Tue, 9 Oct 2001, Jeffrey W. Baker wrote:
>
>
> On Wed, 10 Oct 2001, Luigi Genoni wrote:
>
> > and what is the content of
> > /proc/net/ip_conntrack
> > file?
> >
> > how big is the buffer you are using for packet tracing?
> > (/proc/sys/net/ipv4/ip_conntrack_max)
>
> Well, I'm not going to send that file to the Internet at large, but
> ip_conntrack current has about 2100 lines and the max is 65535.
>
> -jwb
>
On Tue, 9 Oct 2001 10:07:05 -0700 (PDT)
"Jeffrey W. Baker" <[email protected]> wrote:
> On 9 Oct 2001, Trever L. Adams wrote:
>
> > I am seeing messages such as:
> >
> > Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
> > SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
> > ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
> > URGP=0
> >
> > In my firewall logs. I see them for ACK RST as well. These are valid
> > connections. My rules follow for the most part (a few allowed
> > connections to the machine in question have been removed from the
> > list). This often leaves open connections in a half closed state on
> > machines behind this firewall. It also some times kills totally open
> > connections and I see packets rejected that should be allowed through.
>
> I see this too. iptables is refusing packets on locally-initiated TCP
> connections when the RELATED,ESTABLISHED rule should be letting them
> through.
Yes, but it has forgotten them. Play with the TCP timeout numbers in
net/ipv4/netfilter/ip_conntrack_proto_tcp.c. Especially the 60 seconds for
TCP_CONNTRACK_CLOSE_WAIT for the ACK FIN case. These numbers were stolen
from the 2.0 and 2.2 masq code, which had real world testing (but didn't
report failures, so...)
Given some actual feedback on appropriate numbers, this can be fed as a
patch to Linus...
Hope that helps,
Rusty.
Trever L. Adams([email protected])@2001.10.09 13:30:14 +0000:
> The big problems I have are a few websites and digitalme.com (all
> services... web, mail, etc.).
Whats the content of /proc/sys/net/ipv4/tcp_ecn ?
/Benno
--
Sebastian Benoit <[email protected]>
OpenPGP-Key ID 0x82AE75E4
fingerprint 0BDA 0CB7 9BCA AF77 28EE D91A 396D 93BC 82AE 75E
The trouble with political jokes is that they get elected.
I have been running 2.4.10-ac11 for 7 days now with
TCP_CONNTRACK_CLOSE_WAIT set to 120 seconds - this has stopped nearly
all firewall activity on established connections.
I use "mc" extensively for ftp, and previously would get numerous blocks
after closing a session or starting another ftp session with the same
instance of "mc".
What would we need to do to make these values tuneable either via
insmod/modprobe or /proc?
Darrell
On Wed, Oct 10, 2001 at 01:55:03PM +1000, Rusty Russell wrote:
> On Tue, 9 Oct 2001 10:07:05 -0700 (PDT)
> "Jeffrey W. Baker" <[email protected]> wrote:
> > On 9 Oct 2001, Trever L. Adams wrote:
> > > I am seeing messages such as:
> > > Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
> > > SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
> > > ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
> > > URGP=0
> > >
> > > In my firewall logs. I see them for ACK RST as well. These are valid
> > > connections. My rules follow for the most part (a few allowed
> > > connections to the machine in question have been removed from the
> > > list). This often leaves open connections in a half closed state on
> > > machines behind this firewall. It also some times kills totally open
> > > connections and I see packets rejected that should be allowed through.
> >
> > I see this too. iptables is refusing packets on locally-initiated TCP
> > connections when the RELATED,ESTABLISHED rule should be letting them
> > through.
>
> Yes, but it has forgotten them. Play with the TCP timeout numbers in
> net/ipv4/netfilter/ip_conntrack_proto_tcp.c. Especially the 60 seconds for
> TCP_CONNTRACK_CLOSE_WAIT for the ACK FIN case. These numbers were stolen
> from the 2.0 and 2.2 masq code, which had real world testing (but didn't
> report failures, so...)
>
> Given some actual feedback on appropriate numbers, this can be fed as a
> patch to Linus...
>
> Hope that helps,
> Rusty.
On Fri, 19 Oct 2001 06:18:30 -0700
Darrell A Escola <[email protected]> wrote:
> I have been running 2.4.10-ac11 for 7 days now with
> TCP_CONNTRACK_CLOSE_WAIT set to 120 seconds - this has stopped nearly
> all firewall activity on established connections.
OK... I think this needs changing then. Can everyone please try the following
trivial patch and report any changes?
Thanks!
Rusty.
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sun Apr 29 06:17:11 2001
+++ working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Wed Oct 24 14:23:26 2001
@@ -55,7 +55,7 @@
2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */
2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */
10 SECS, /* TCP_CONNTRACK_CLOSE, */
- 60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */
+ 2 MINS, /* TCP_CONNTRACK_CLOSE_WAIT, */
30 SECS, /* TCP_CONNTRACK_LAST_ACK, */
2 MINS, /* TCP_CONNTRACK_LISTEN, */
};
On Oct 24, 2001, Rusty Russell wrote:
> On Fri, 19 Oct 2001 06:18:30 -0700
> Darrell A Escola <[email protected]> wrote:
>
> > I have been running 2.4.10-ac11 for 7 days now with
> > TCP_CONNTRACK_CLOSE_WAIT set to 120 seconds - this has stopped nearly
> > all firewall activity on established connections.
>
> OK... I think this needs changing then. Can everyone please try the following
> trivial patch and report any changes?
Running 2.4.4 with this patch for the past 4 days has reduced the number of
inappropriately dropped packets by ip_conntrack to nearly zero. The number
of legitimate packets that used to be dropped previous to running this patch
would sometimes reach into the low hundreds over the same time frame. (FWIW,
I have a cable modem connection to the 'net, and so it gets a bit slow from
time to time since my bandwidth is shared...).
--Mike
> diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
> --- linux-2.4.12-official/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sun Apr 29 06:17:11 2001
> +++ working-2.4.12-tcptime/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Wed Oct 24 14:23:26 2001
> @@ -55,7 +55,7 @@
> 2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */
> 2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */
> 10 SECS, /* TCP_CONNTRACK_CLOSE, */
> - 60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */
> + 2 MINS, /* TCP_CONNTRACK_CLOSE_WAIT, */
> 30 SECS, /* TCP_CONNTRACK_LAST_ACK, */
> 2 MINS, /* TCP_CONNTRACK_LISTEN, */
> };
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Michael B. Rash
http://www.cipherdyne.com
Key fingerprint = 8E40 0826 4BBD 9DAF 4563 695C AC21 A428 70C9 B006