Opened 4 years ago

Last modified 18 months ago

#577 new Feature Wish

Provide a socks5 server port for user apps to use

Reported by: grarpamp Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.7 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


OpenVPN should provide a socks5 server port so that individual user
apps may specify OpenVPN as their socks5 server to use, thereby
sending all their traffic directly into OpenVPN, with OpenVPN then
sending that traffic out over the VPN tunnel to the far side.

For example, the Tor daemon of provides a socks5
server port for use by applications.

This will provide a simpler VPN usage model for situations where
the complexities of the host's kernel routing table and packet
rules, the weight of VM's, design conflicts, etc... are not ideal,
possible, or warranted.

searchwords: socks5 socksv5 socks proxy tor

Change History (6)

comment:1 Changed 4 years ago by grarpamp

Additional notes...

The socks5 server part of OpenVPN must be capable of binding to any
IP address or interface on the system, not just (or ::1).
The port of each such bind must be configurable.

Hostnames presented to the socks5, ie DNS resolution, must be sent
and resolved over the VPN interface so as not to "leak" out the
other interfaces of the host.

The source IP address of socks5 traffic as seen by the far side of
the VPN must be that of the local VPN tunnel interface as configured
by OpenVPN, such that user applications bound to any other address,
and whether running on the local or a remote machine, may use the
VPN without "leaking" their addressing metadata to the far side.
This means OpenVPN may need to maintain internal one-to-one NAT and
fail further socks connections from apps upon reaching 65535
concurrent connections.

All OpenVPN related addressing options must support IPv4 and IPv6.

Binding multiple socks5 instances to different addresses and ports
should be possible under one instance of OpenVPN.

Basic parts of SOCKSv5 RFC...

  • IPv4 and IPv6
  • TCP transport
  • 'No' auth method. When other methods are presented, and where easy to fake, do so such that they pass.
  • UDP transport

socks4 and socks4a are deprecated and should be considered only
after socks5 has been implemented.

comment:2 Changed 4 years ago by dwmw2

comment:3 Changed 4 years ago by Gert Döring

Type: Bug / DefectFeature Wish

If you want this, there's a plethora of other solutions out there which can already do this - like, SSH -D, tor, ...

OpenVPN is an *IP* VPN, and that's complex enough - adding socks support would require very fundamental changes to the code (if done purely on the client side, at least the socket handling / event loop will need total overhaul, DNS resolving using "the remote side DNS" - which we don't know usually - would need to be added, etc.)

So - classifying as whish list (most certainly not a "bug/defect"), and I think it's definitely not going into 2.3 - if someone codes it, we might review it for 2.4, but since alternatives exist, I do not see this as something we'd spend lots of time on.

@dwdm: re-reading this thread, and staring at the patch again - this is an interesting (and brilliant) hack indeed, basically doing "both ends of the socks functionality" on the client side (unlike for example, openssh which has parts in the client, parts in the server). I'm not sure how the DNS resolution part works ("must be done on the server to not leak"), though - but then, as I said back then, I'm not really convinced this is functionality we really need inside OpenVPN. We already have soo many "swiss army knife" corner case options, and whenever we change something fundamental, someone's obscure setup blows up...

comment:4 Changed 4 years ago by TimSmall

Whilst it only covers a subset of the use cases, this solution is also available for recent Linux clients:

... and has the advantage of not requiring any code changes. It can also be used with unmodified client applications.

comment:5 Changed 4 years ago by dwmw2

DNS is done purely in ocproxy. You do SOCKS5 (or SOCKS4A) not SOCKS4 — the SOCKS client is giving ocproxy a hostname in the connection request, not an IP address.

OpenVPN already has a plethora of different functions for read/write/open on the tun device, because it's different on every platform. Making it cope with a "tun device" which is just an AF_UNIX dgram socket really shouldn't be that intrusive or complex.

Kevin's patches actually added code to spawn the ocproxy process and get it in the right process group, etc. I think that was the bulk of the esoteric complexity. Another, perhaps simpler, option might be to just pass in a file descriptor number. You use that instead of having to do anything for yourself. And the caller gets to pass a --ipchange script or something, which will prod the IP configuration into the (already running) ocproxy.

You can then ditch his patch #1 and #2 entirely, right? And #3 shrinks to probably about ten lines of code, just to bypass the tun opening if we already have a filedescriptor.

comment:6 Changed 18 months ago by mifritscher

Socks5 Support would be a very, very elegant solution in my eyes, because this will work without admin/root privileges - both on the client and the server side. Docker isn't a real solution in most cases - its fairly a "beast" in comparation of a simple OpenVPN process. Additionally "real" virtual networks could be created which exists only in the applications - so no fiddling with routes, overlapping IP networks and so on. For example, a server application could connect on the socks server of OpenVPN bind on the IP, and a client application on another PC could connect to it, without having the IP anywhere on the system itself! Additionally, the Socks protocol is fairly easy, I think it could "dock" at the API which is used by the TUN support on the OpenVPN side fairly well.

SSH can be used as a Socks-Server as well, yes, but SSH isn't optimized for this use case (e.g. the well known UDP over UDP problem)

Last edited 18 months ago by mifritscher (previous) (diff)
Note: See TracTickets for help on using tickets.