Ramin,
-> 1) Are these IP fragments? If so, Why is it happening especially with
-> such a short length.
No, they are not fragments.
I did some sniffing on the firewall outside interface and the
interface of the target server, also outside the firewall. I wanted to see
if that partial packet ever gets out. I discovered that it doesn't, hence
the non-ack, and hence the login not being completed.
-> 3) If these are not fragments and are seperate TCP segments
-> leaving the
-> client, you should actually wonder why your firewall is
-> not passing
-> packet 3. Do you have any rules droppng these packets.
Well, the only forward rule I have in place is to drop NEW state packets
where SYN is unset. Not that is this only set (allegedly) on inbound packets
coming to the external interface.
$IPTABLES -A FORWARD -p tcp -i ${EXTERNAL} ! --syn -m state --state
NEW -j LOG --log-level DEBUG --log-prefix "New not syn:"
$IPTABLES -A FORWARD -p tcp -i ${EXTERNAL} ! --syn -m state --state
NEW -j DROP
The packet in question *should* go through, since it's going *outbound*
through the internal interface and out the external. Note how this rule
appears with "iptables-save" output:
-A FORWARD -i eth0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m
state --state NEW -j LOG --log-prefix "New not syn:" --log-level 7
-A FORWARD -i eth0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m
state --state NEW -j DROP
However, note the difference with "iptables -L":
LOG tcp -- anywhere anywhere tcp
flags:!SYN,RST,ACK/SYN state NEW LOG level debug prefix `New not syn:'
DROP tcp -- anywhere anywhere tcp
flags:!SYN,RST,ACK/SYN state NEW
No matter which way the packet goes, however, it should go. The flags don't
match the above condition. Here's the TCP data from the packet:
Transmission Control Protocol, Src Port: 51683 (51683), Dst Port: ftp (21),
Seq: 2918629815, Ack: 860652908
Source port: 51683 (51683)
Destination port: ftp (21)
Sequence number: 2918629815
Next sequence number: 2918629816
Acknowledgement number: 860652908
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 8760
Checksum: 0xc688 (correct)
File Transfer Protocol (FTP)
Request: P
I'm wondering if the packet filter is reading this packet as a NEW
state. I'm not clear on how the connection tracking module does that, so if
someone could explain it, I might have another clue to the problem. As a
contrast, here's the same packet segment as above, except when we did a
manual, command-line initiated ftp. Note that the only real difference is
the dta sent:
Transmission Control Protocol, Src Port: 51686 (51686), Dst Port: ftp (21),
Seq: 2919310519, Ack: 37284046
Source port: 51686 (51686)
Destination port: ftp (21)
Sequence number: 2919310519
Next sequence number: 2919310534
Acknowledgement number: 37284046
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 8760
Checksum: 0xb575 (correct)
File Transfer Protocol (FTP)
Request: PASS
Request Arg: XXXXXXXX
I'm stumped.
Thanks.
Joe
