I needed SSH/SFTP/git against hosts behind a corporate OpenVPN, without routing my whole machine through the tunnel and without sudo, a TUN device, Docker or a VM. Every existing option I found either takes over system routing/DNS or needs a container.

So OvpnLane speaks OpenVPN on one side and exposes a plain SOCKS5 listener on 127.0.0.1:1080 on the other. Only what you point at the proxy goes through the VPN:

ovpnlane --config client.ovpn ssh -o 'ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p' user@10.8.0.10 curl --proxy socks5h://127.0.0.1:1080 https://internal.example 

No kernel interface is created. VPN addresses, routes and pushed DNS are applied to an in-process stack, not to the host.

This project is loosely inspired by openvpn2socks and was developed with a lot of help from OpenAI Codex: implementation, debugging, tests, docs and the release workflow. I'm saying it up front because I think you'd rather know than guess, and because it affects how much you should trust the code.

Known limits

• SOCKS5 CONNECT only. BIND and UDP ASSOCIATE return command-not-supported, even when the OpenVPN transport is UDP.
• DNS over the tunnel is UDP-only: no TCP retry, no search domains, no Happy Eyeballs. Dual-stack: A first, AAAA fallback, first address wins.
• No TAP, no compression, no DCO, no external PKI/smart cards, no browser SSO, no dynamic challenge. remote-cert-tls server is required.
• Server PUSH_UPDATE is reported as an error; restart the process.
• No auth on the loopback SOCKS listener: any local process/user can use it.
• No benchmarks yet. Buffers and queues are bounded but I haven't measured throughput vs. a kernel TUN.
• Linux release binaries are glibc x86_64 only (no musl, no ARM64 yet). Binaries are not notarized/signed.
• It's a C++ core wrapped in Rust, not a pure-Rust OpenVPN. If that's a dealbreaker for you, fair enough.

What I'd like feedback on

1. The thread + crossbeam select! + custom Waker design for driving smoltcp from Tokio. Is there a cleaner pattern people have settled on (e.g. running smoltcp inside a LocalSet, or a Notify-based loop)?
2. Whether the generation-id approach for discarding stale packets across reconnects has holes I'm not seeing.
3. Anyone with experience of openvpn-connect-rs / OpenVPN 3 Core external TUN in production.

Issues and PRs welcome. Happy to answer anything about the internals.