Discussion: server-side tun2socks

[fortuna]

One big pain of implementing Shadowsocks clients is mapping IP packets to TCP streams and UDP associations. Furthermore, it restricts the protocol support, you can't do ICMP, for instance.

A different design would have the client establish an encrypted connection (shadowsocks minus "socks") to the proxy server, and send IP packets over it, with the server working as a simple NAT. One nice thing about this is that client connections to the destination can survive network changes.

Has this been explored? If yes, what were the conclusions? If not, why not?
For instance, the stream mapping is not an issue when you are running a local SOCKS proxy client like ss-client on desktop, and sending IP packets conflicts with the local proxy approach. But it would still be very helpful in the common case of running a full system VPN as in the mobile apps.

I know there are issues with TCP over TCP, but you can mitigate that. For instance, you can increase the retransmission timeout on the tun device, or prefer TCP over UDP.

[Mygod]

Has this been explored?

That's called a VPN. https://github.com/clowwindy/ShadowVPN

https://www.wireguard.com/

[riobard]

@fortuna Packet-oriented VPN isn't as flexible as stream-oriented Shadowsocks (and similar tools), and is difficult to create performant implementations in userspace.

[database64128]

Instead of looking for ways to retrofit L3 packets into a L4 tunnel protocol like Shadowsocks, we can simply use a VPN to encapsulate IP packets and forward them using a simple proxy. An hour ago I finished database64128/swgp-go, a simple proxy with minimal overhead for WireGuard traffic. There are two operating modes:

• AES block encrypt the first 16 bytes of all packets. Pad handshake packets to remove packet length characteristics. No impact on tunnel MTU. (Zero-overhead mode)
• Optionally, pad all packets and XChaCha20-Poly1305 encrypt the whole padded packet. 42-byte overhead. (Paranoid mode)