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... 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 * 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. Regards Henrik
