Checkpoint behaviour will depend on the version that you're running, pre v4.1 SP2, FW-1 would allow your ACK through to the destination host irrespective of the time since the initial SYN was sent, as long as there is a rule explicitly permitting your source -> destination TCP connection. In this instance, any RST that you may happen to receive would come from the real destination server. Current service pack patched FW-1's wouldn't generaly send a RST even if you waited for more than 60 seconds after sending the SYN, it'd just drop the ACK packet and take no action (this depends upon the policy that's installed of course). I presume that a PIX would behave in a similar fashion, although I don't know much about them. For a proxy-based firewall like Gauntlet I would presume that the firewall would exhibit the TCP behaviour of the OS that it runs on, and that you'd get different responses for Gauntlet on different OSes. Does this sound feasible to others? Rgds, Paul -----Original Message----- From: Mr.P.Taylor [mailto:petert@imagine-sw.com] Sent: Wednesday, May 30, 2001 9:47 PM To: PEN-TESTat_private Subject: identifying if checkpoint uses a 60sec timeout for establishing a 3way and PIX uses a 300sec timeout (which seems too large but it's all the info I could find on it) and Gauntlet uses ??? could you not just send the intial syn wait the timeout value then try to complete the handshake? After exceeding the timeout value would the socket not be closed and would you not get a RST back thus identifying by timeout?
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 14:00:16 PDT