On Fri, 19 Nov 1999, Alan L Milne wrote:
> For the 1st case the source IP,source port, destination IP and
> destination port are the same for all 4 SYNS.
I forgot to ask you the time between each attempt. Is it a connection
retry after a timeout or simply some packet sent just to be sent ?
>
> For the 2nd case the IP addresses and ports are the same (i.e. a two-way
> communication has been established).
>
> Just to clarify things,
>
> - In the first case - if a firewall was so configured then would it
> only DROP the SYN packets and not send ANY kind of TCP response (i.e.
> not even a RST?)?
As discussed a month ago in this mailing list, it seems that this
behaviour is "correct".
(check http://uwsg.ucs.indiana.edu/hypermail/linux/net/9910.3/0081.html)
Another explication could be that the syn packet is blocked by his own
firewall. In this case, the host B don't ever know about this packet.
(Maybe you must use a TIS gateway to gou out ?)
>
> - I don't believe a firewall is responsible for the second case as:
> (i) Why should a SYN_ACK be sent back in response?
> (ii) Because the ACK (3-way connection establishment) is from the same
> HOST as the SYN and we saw the SYN then we SHOULD see the ACK (if it was
> sent). The only
> conclusion would seem to be that the ACK isn't sent. This would violate
> RFC793 and so we can only assume that the application which originated
> the SYN doesn't really want to establish a valid two-way communication.
>
> - Over the duration of 15 mins I recorded lots of the 1st and 2nd case
> type flows. Neither of them were terminated by RST or 4-way handshake
> FIN/ACK sequences - which for the second caseleads me to point the
> finger at IP Spoofing by a source who doesn't care about terminating the
> connection properly - what do you think?
Yes it could be. and the host A is the one who is trying to do so.
But maybe ther is another router between you and host A drop the packet.
Maybe A is trying to setup masquerading (for VMware for
example) unsuccessfully or have pb with ipchains rules...
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
