Don Cohen wrote: > > Because there is no good way to know the servers TCP options before > > you have opened the TCP connection to the server, and you do not > > want to open the TCP connection to the server before the client has > > acknowledged the connection... > > Fortunately, all of these options are ... optional, so the firewall > can, if it doesn't know better, simply not use them.
To ensure interoperability you must also filter out any options on future packets of that TCP not known to be 100% compatible with your SYN+ACK. > The timestamp option is not a problem in this case. The firewall only > responds to a few packets and for those it can supply its own > timestamp (or not). After it establishes both halves of the > connection it just forwards the packets and the timestamps (seems to > me) should work out fine. The timestamp option must be real all the time, or never. You cannot suddently switch TCP timestamp source in the middle of a TCP connection. Doing so will serverely break PAWS. Note: The TCP timestamp option is not the same as the IP timestamp option. TCP timestamps has nothing to do with time, only the progress of relative time within a TCP. Regards Henrik
