Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[feralertx]

Hi everyone,

Having a look at the iptables log i see quite a few outgoing TCP packets being dropped such as this one (16442 being the TCP port configured in preferences and 192.168.11.3 my pc ip):

Aug 29 20:51:24 Tatoo kernel: DROP OUT INVALID IN= OUT=br0 SRC=192.168.11.3 DST=58.63.24.159 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=63202 DF PROTO=TCP SPT=16442 DPT=14008 WINDOW=6432 RES=0x00 ACK FIN URGP=0

And this is the iptables rule that matches and drops it (its the first one):

$IPT -A OUTPUT -m state --state INVALID -j LOG --log-prefix "DROP OUT INVALID " --log-ip-options --log-tcp-options
$IPT -A OUTPUT -m state --state INVALID -j DROP

Using wireshark i have seen some connections being closed properly -I think- with the four-ways handshake, iniciating with the same kind of tcp packet we saw in the dropped example (FIN,ACK), i put this one as an example (copied from wireshark):

278   4.195628   192.168.11.3   85.18.136.105   TCP   16442 > 21627 [FIN, ACK] Seq=1 Ack=1 Win=6432 Len=0
289   4.605954   85.18.136.105   192.168.11.3   TCP   21627 > 16442 [ACK] Seq=1 Ack=2 Win=65535 Len=0
290   4.611528   85.18.136.105   192.168.11.3   TCP   21627 > 16442 [FIN, ACK] Seq=1 Ack=2 Win=65535 Len=0
291   4.611571   192.168.11.3   85.18.136.105   TCP   16442 > 21627 [ACK] Seq=2 Ack=2 Win=6432 Len=0

Im on debian lenny using the precompiled amule deb package from  vollstreckernet and a manually compiled 2.6.24 kernel.
Amule details:

$ amule -v
aMule SVN using wxGTK2 v2.8.7 (Snapshot: Wed Aug 20 07:01:59 CEST 2008) (OS: Linux)

What do you think? Is this aMules fault or is iptables dropping wrong packets? Or is it me doing something wrong (very likely though ) ?

Thanks!

[lfroen]

Care to explain why did you added iptables rule in a first place? aMule doesn't handle IP packets, it's TCP stack responsibility, I hope you know that.

[feralertx]

Care to explain why did you added iptables rule in a first place? aMule doesn't handle IP packets, it's TCP stack responsibility, I hope you know that.

Care to explain why i shoudnt? Firewalls are for security and 'invalid' packets (=meaning that the packets are not associated with an existing connection) are usually sent by people with no good intentions, I hope you know that... actually i dont, since i dont expect people to know about everything. What i do expect from people is to show some politeness, but i guess thats expecting too much.

Anyway, thanks for the reply.

[skolnick]

I would say it's iptables fault. It looks to me like aMule is sending the FIN message to the peer (which should indicate that aMule tries to finish a connection with that peer) but somehow iptables thinks the connection already ended (or never existed) and drops and logs the packet as invalid. It would be useful to get a wireshark capture of a dropped packet, maybe that way you can figure what's wrong and correct it.

Regards.

[lfroen]

Firewalls are for security and 'invalid' packets (=meaning that the packets are not associated with an existing connection) are usually sent by people with no good intentions

You're adding rule for outgoing traffic. Those are packets your computer send.

I hope you know that... actually i dont

Setting rule for your own traffic indicate that there are lot of things you clearly don't know. "TCP/IP illustrated" and "Routing Internet" are great books.

skolnick
IIRC this situation (FIN packet sent after connection is closed) is pretty common. See, the iptables track connection status independently from TCP stack.   There's lot of outgoing traffic, and transmit queue is full. Generally, incoming bandwidth is higher that outgoing, so if peer send you FIN and you send FIN,ACK, your packet can be delayed quite a bit, so by the time it's transmitted, connection is already dead. iptables see this as "invalid".

[skolnick]

lfroen:

Hmm...I am not sure if a FIN packet is valid after the connection is ended...after all, that's what FIN scans are, they are used for fingerprinting, and they are not exactly valid (in the sense of TCP/IP specification) traffic. In fact, iptables blocks FIN packets that are not related to an already-established connection. However, your explanation of the issue sounds like what the OP is seeing.

Regards.

[lfroen]

"Validity" is not the point here. It's not "valid" in sense that TCP stack will silently reject such a packet without changing state. However, it is valid in sense that such packet can appear under normal circumstances.
BTW: that's why FIN scanning works.

[skolnick]

It's exactly what I meant. A FIN packet with no current connection made is not valid for the TCP stack, however you can craft it or whatever packet you want and send it to any destination. It's the destination's problem to know what to do when it gets it.

regards.