This is one of the *big* problems I see. The recovery mechanism to get around this requires an intelligent client (ie: not Windows 95) and the ability to recover state (ie: the client knows the state, too (ie: not Linux-style "masqueraing").

Couldn't state be inferred from the retry packets?

It would be nice to pull out the rewriting stuff into loadable rule sets.

Socks really wants two additional tunnel-to-socks and socks-to-tunnel daemons written; using two private nets, this would let you run a private net of socks-unaware hosts that get their packets proxied by setting up a default route, a private net route to one tunnel on one private net, and a default route to the other tunnel on the private net with the dumb hosts. Effectively, a gateway LLB in user space.

I'm trying to picture this, but I'm crippled by lack of understanding of the tunnel device. There is a box, G. It has a network interface, I(G), on the Internet. It has a network interface, P(G), on a private net. Hosts on network P route through P(G) to get out through I(G). G is implementing masquerade, then. I don't understand what you are saying about the structure of the implementation.

> 4. It's not a general purpose solution (e.g. ICMP doesn't work...

The is the second of the *big* problems.

I don't understand why it is a big problem. It is a big problem if you are trying to put the private machines on the Internet, but I don't see that as being the goal. The goal is to get TCP applications (and secondarily UDP applications) to run transparently from a private network home through an Internet gateway.

If the gateway violates host requirements, *that* is a problem.