OCPROXY(1)

πŸ“¦
version 1.60 Β· 2 versions
  • 1.60 Β· debian bookworm, debian trixie, nixos 26.05, nixpkgs unstable, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 1.60 Β· fedora 43, fedora 44
, in debian bookworm, debian trixie, nixos 26.05, nixpkgs unstable, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– OCPROXY(1) β€” the manual page, but make it bestie πŸ’–

okay so real talk, this is the manual for ocproxy from the General Commands Manual, and it's genuinely one of those tools that just works once you get it. let's go ✨


🌸 NAME 🌸

ocproxy β€” a lwip based proxy for openconnect πŸ¦‹


✨ SYNOPSIS ✨

ocproxy [options]

that's it bestie, that's the whole vibe. no positional args, no drama πŸ’…


πŸŽ€ DESCRIPTION πŸŽ€

okay so this page is just gonna briefly walk you through the ocproxy command. lowkey short, highkey useful 🫢

ocproxy is a program that gives you a SOCKS proxy and port-forwarding proxy when you use it together with openconnect(1). and here's the iconic part: when you're running ocproxy, OpenConnect only handles the network activity that you specifically ask it to proxy. so the VPN tunnel no longer "hijacks" all the network traffic on your host. no more main-character-syndrome VPN eating everything πŸ˜­πŸ‘‘

how does it pull this off?? by running a lwIP network stack in userland, so the OS kernel isn't directly handling the packets going to and from the VPN connection anymore. the kernel is like, not invited. periodt βœ‹


🌈 BASIC USAGE 🌈

ocproxy should be invoked directly from OpenConnect or another VPN program. a file descriptor number gets passed through the VPNFD environment variable, and that's how ocproxy knows how to send and receive VPN traffic. iykyk πŸ’«

like, for example:

openconnect --script-tun --script "ocproxy -D 11080
-L2222:unix-host:22" vpn.example.com

the options people actually use all the time are these ones πŸ‘‡

  • -D, --dynfw [bind_address:]port β€” starts up a SOCKS5 server on TCP port port so you can dynamically forward application-level traffic over the VPN proxy. it's meant to feel like the -D option in ssh(1). if you don't specify bind_address, ocproxy binds to the loopback interface by default β€” unless you used --allow-remote, in which case, plot twist πŸŒ€
  • -L, --localfw port:host:hostport β€” binds to local TCP port port and forwards incoming connections to host:hostport on the VPN. host can be a DNS name or a dotted-quad IP address, flexible queen πŸ’β€β™€οΈ. and if the VPN handed over a default DNS domain name, or you passed --domain on the command line, then unqualified hostnames are fair game too. this is meant to resemble the -L option in ssh(1).
  • -g, --allow-remote β€” so by default, the local listening sockets opened by --dynfw and --localfw are bound to the loopback interface only (127.0.0.1), which means they're only reachable from the local machine. if you specify --allow-remote, those sockets get bound to INADDR_ANY (0.0.0.0) instead, and other hosts can connect to them πŸ‘€. this is intended to resemble the -g option to ssh(1).
ngl bestie, think before you flip this one on β€” it literally opens your proxy up to other machines 🚨
  • -k, --keepalive interval β€” sends a TCP keepalive packet every interval seconds on each open connection, on the VPN side. this helps you dodge idle timeouts, both on the VPN gateway itself and on any stateful firewalls sitting in between the two ends. staying alive, literally ✨

πŸ’œ ADVANCED USAGE πŸ’œ

these ones are for when you're debugging ocproxy or trying to diagnose a problem. detective mode πŸ”

  • -v, --verbose β€” turns on verbose debugging output. more words, more truth πŸ—£οΈ
  • -T, --tcpdump β€” writes a log of all TCP or UDP packets traversing the VPN to /tmp/tcpdump. the format largely mirrors the output of the tcpdump(8) utility. cute little packet diary πŸ““

normally ocproxy grabs its IP configuration parameters through environment variables that OpenConnect provides. but these options below let you override the autodetected parameters, if you're feeling opinionated πŸ’…

  • -I, --ip local_ip β€” uses local_ip as the VPN side IP address. example: 192.168.5.20. this is normally set through the INTERNAL_IP4_ADDRESS environment variable.
  • -M, --mtu mtu_bytes β€” uses mtu_bytes as the maximum transmit unit on the VPN interface; it generally depends on DTLS and UDP packet overhead. example: 1300. this is normally set through the INTERNAL_IP4_MTU environment variable.
  • -d, --dns dns_ip β€” sends all VPN side DNS queries to server dns_ip. example: 192.168.5.2. this is normally set through the INTERNAL_IP4_DNS environment variable.
  • -o, --domain domain β€” uses domain as the default DNS domain, for unqualified hostnames. this is normally set through the CISCO_DEF_DOMAIN environment variable.

πŸ¦‹ SEE ALSO πŸ¦‹

and if you wanna go read the lwIP lore: http://savannah.nongnu.org/projects/lwip/ 🌐


okay that's the whole page bestie!! this one's from the General Commands Manual, it's ocproxy(1), and it was dated November 20, 2012 β€” vintage, honestly, and still slaying πŸŽ€βœ¨