> Don Cohen wrote: > > > Why do you think that's better than simply forwarding packets with > > sequence/ack# translation? Surely it's less efficient. And it raises > > questions about how much data to buffer between the two and how that > > can be controlled. > > 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.
> Adjusting the sequence numbers is the simple part of the picture. Does not > worry me.. this is what the NAT engine is doing. > > What worries me is > > * Window scaling It would be unfortunate to lose this in some cases, but those are the cases where the firewall is likely to know what sort of window scaling is supported by the server. > * Timestamp > * ECN > > and a number of other end-to-end TCP options that depend on correct > negotiation during SYN. > > Sure, window scaling and ECN can be set by configuration if you know your > server, but there is no good way to deal with the timestamp option short of > forcibly filter it out entirely from the TCP stream. 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.
