On Oct 27, 2005, at 6:24 AM, Steve Campbell wrote:
> ----- Original Message ----- From: "Vadim Kurland /?/"
> To: "Steve Campbell" <campbell@...>
> Cc: <fwbuilder-discussion@...>
> Sent: Wednesday, October 26, 2005 10:09 PM
> Subject: Re: [Fwbuilder-discussion] OT: question about reverse(?)
>> On Oct 26, 2005, at 6:06 AM, Steve Campbell wrote:
>>> I am seeing what appears to be reverse port packets, mostly
>>> using HTTP (port 80), but not exclusively so.
>>> Put another way, the source port is 80, and the destination port
>>> is the regular high response port. This is reversed from the way
>>> I usually see them. They are almost like reply packets.
>> check TCP flags in these packets. Is FIN flag set ? If yes, these
>> are likely closing packets of TCP sessions opened by computers
>> inside your network to various web servers on the Internet.
>> Sometimes iptables purges state information sooner than the final
>> TCP FIN packet comes, in which case this packet does not match
>> any state and is dropped and logged.
> Is this what you are saying:
> Original valid packet could be:
> SRC IP xx.xx.xx.xx DPort 80 DST IP yy.yy.yy.yy
> Reply for setup ports then could be:
> SRC IP xx.xx.xx.xx SPort 111111 DPort 80 DST IP yy.yy.yy.yy
not sure what is the "reply to setup ports" is.
say, client is x.x.x.x and server is y.y.y.y. Client's port is
ephemeral, that is, it is above 1024. Say, it is 1111. Server port is
80. I'll use notation address:port. It is important to track tcp flags.
Opening connection involves 3 packets:
x.x.x.x:1111 -> y.y.y.y:80 SYN
y.y.y.y:80 -> x.x.x.x:1111 SYN ACK
x.x.x.x:1111 -> y.y.y.y:80 ACK
the firewall keeps track of these packets and creates a memory
structure for this session to monitor it in the future. It identifies
this structure by a tuple: clients address, clients port, servers
address, servers port. These four values uniquely identify
established tcp session.
Closing connection normally involves four packets, but it really
depends on which agent initiates closing, but in the end each side
needs to close its connection separately. Suppose it is the client
who wants to close connection
x.x.x.x:1111 -> y.y.y.y:80 FIN
y.y.y.y:80 -> x.x.x.x:1111 ACK
y.y.y.y:80 -> x.x.x.x:1111 FIN
x.x.x.x:1111 -> y.y.y.y:80 ACK
If iptables purges state entry from memory after it sees the first
FIN-ACK exchange, the FIN packet coming from the server won't
correspond to any session known to iptables and will be dropped.
Another possibility is that the state was not purged and FIN packet
from the server has been received, but client's ACK got lost
somewhere because of packet loss on the network or incorrect behavior
of firewall or load balancer on the server's side, but since iptables
has seen client's ACK, it purged the state already. Since the server
never saw the ACK, it retransmits the FIN, which does not correspond
to any known session in iptables and gets dropped. Normally, TCP/IP
stack maintains state called "2MSL timeout" after the last ACK is
sent specifically to be able to retransmit it. Iptables does not
follow this and purges state immediately, this may lead to these
weird dropped FIN packets.
There are also other possibilities. Modern browsers try to maintain
open tcp connection to the server in order to speed-up download of
the subsequent pages. If the firewall times out its internal
representation of the session while both the client and the server
still keep it open but do not pass any packets, their attempt to
gracefully close it will be blocked by the firewall because it won't
match any known state.
Obviously all this is based on the assumption that the packets you
see in log have FIN flag set, which you never confirmed in the first
There is always a possibility of a port scan, too. Port scan may look
different in the log depending on how sophisticated it is. Check
source addresses and destination ports, see if there is a pattern.
Try to connect to one of the web servers whose address appear in the
log, see if you can trigger the effect and get new log entry once the
page finishes loading or some time after that. If you do, it would be
an indication of the stray packets coming when the state entry is
purged rather than port scan.
Couple of urls:
(specifically 2.4 and 2.5)
> A iptable purge occurs, dropping the state information, now
> reversing source and destination IPs for a late reply from the real
> DST IP
> DST IP xx.xx.xx.xx DPort 11111 SPort 80 SRC IP yy.yy.yy.yy
> IPtables only knows source and destination from state tables, or
> the packet has a certain protocol indicating which is source and
> I guess this is what is confusing me. If this first part of the
> above statement is a good rationale for what is happening, I'm OK
> with that and have learned something new. If the latter part of the
> above statement is better, I need to know how the protocol was
> reversed as this maybe a problem.
> Any thoughts?
> Thanks for the time and effort!
> Steve Campbell
> Charleston Newspapers
>>> They are being blocked, but is this normal? Or should I being
>>> looking on my servers for something causing this. Ages ago, I
>>> saw this with DNS, and Mr. Kurland explained this to me. But
>>> this is the first time I have seen this with services other than
>>> Any explanation would be appreciated. Thanks.
>>> Steve Campbell
>>> Charleston Newspapers
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> Fwbuilder-discussion mailing list