ocproxy is a user-level SOCKS and port forwarding proxy for OpenConnect based on lwIP. When using ocproxy, OpenConnect only handles network activity that the user specifically asks to proxy, so the VPN interface no longer "hijacks" all network traffic on the host.
Commonly used options include:
-D port Set up a SOCKS5 server on PORT
-L lport:rhost:rport Connections to localhost:LPORT will be redirected
over the VPN to RHOST:RPORT
-g Allow non-local clients.
-k interval Send TCP keepalive every INTERVAL seconds, to
prevent connection timeouts
ocproxy should not be run directly. Instead, it should be started by openconnect using the --script-tun option:
openconnect --script-tun --script \
"./ocproxy -L 2222:unix-host:22 -L 3389:win-host:3389 -D 11080" \
vpn.example.com
Once ocproxy is running, connections can be established over the VPN link by connecting directly to a forwarded port or by utilizing the builtin SOCKS server:
ssh -p2222 localhost
rdesktop localhost
socksify ssh unix-host
tsocks ssh 172.16.1.2
...
OpenConnect can (and should) be run as a non-root user when using ocproxy.
tsocks, Dante, or similar wrappers can be used with non-SOCKS-aware applications.
Sample tsocks.conf (no DNS):
server = 127.0.0.1
server_type = 5
server_port = 11080
Sample socks.conf for Dante (DNS lookups via SOCKS5 "DOMAIN" addresses):
resolveprotocol: fake
route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 127.0.0.1 port = 11080
command: connect
proxyprotocol: socks_v5
}
FoxyProxy can be used to tunnel Firefox or Chrome browsing through the SOCKS5 server. This will send DNS queries through the VPN connection, and unqualified internal hostnames (e.g. http://intranet/) should work. FoxyProxy also allows the user to route requests based on URL patterns, so that (for instance) certain domains always use the proxy server but all other traffic connects directly.
It is possible to start several different instances of Firefox, each with its own separate profile (and hence, proxy settings):
# initial setup
firefox -no-remote -ProfileManager
# run with previous configured profile "vpn"
firefox -no-remote -P vpn
Dependencies:
- libevent >= 2.0: *.so library and headers
- autoconf
- automake
- gcc, binutils, make, etc.
Building from git:
./autogen.sh
./configure
make
- Routing traffic from different applications/browsers through different VPNs (or no VPN)
- Connecting to multiple VPNs or sites concurrently, even if their IP ranges overlap or their DNS settings are incompatible
- Situations in which root access is unavailable or undesirable; multiuser systems
It is possible to write a proxy autoconfig (PAC) script that decides whether each request should use ocproxy or a direct connection, based on the domain or other criteria.
ocproxy also works with OpenVPN; the necessary patches are posted here.
ocproxy normally reads its network configuration from the following environment variables set by OpenConnect:
INTERNAL_IP4_ADDRESS: IPv4 addressINTERNAL_IP4_MTU: interface MTUINTERNAL_IP4_DNS: DNS server list (optional but recommended)CISCO_DEF_DOMAIN: default domain name (optional)
The VPNFD environment variable tells ocproxy which file descriptor is used
to pass the tunneled traffic.
Another approach to solving this problem is to create a separate network namespace (netns). This is supported by Linux kernels >= v3.8.
This starts up an application in a fresh user/net/uts/mount namespace:
vpnns -- google-chrome --user-data-dir=/tmp/vpntest
vpnns -- firefox -no-remote -P vpn
vpnns -- transmission-gtk
Initially it will not have any network access as the only interface present in the netns is the loopback device. The application should still be able to talk to Xorg through UNIX sockets in /tmp.
The next step is to connect to a VPN and invoke vpnns --attach to pass
the VPN traffic back and forth:
openconnect --script "vpnns --attach" --script-tun vpn.example.com
openvpn --script-security 2 --config example.ovpn \
--dev "|HOME=$HOME vpnns --attach"
These commands connect to an ocserv or openvpn gateway, then tell vpnns to set up a tunnel device, default route, and resolv.conf inside the namespace created above. On success, the web browser will have connectivity. When the VPN disconnects, the browser will lose all connectivity, preventing leaks.
vpnns can be rerun multiple times if the connection fails or if the VPN
client crashes. If run without arguments, it will open a shell inside the
namespace.
Some differences between vpnns and ocproxy:
- No proxies are involved, so apps should not require any special configuration.
- vpnns is better-suited for hard-to-proxy protocols such as VOIP or BitTorrent.
- vpnns will only ever run on Linux.
- vpnns may interfere with dbus connections.
Unlike previous approaches to the problem (e.g. anything that involves
running ip netns), vpnns does not require root privileges or changing
the host network configuration.
The --name option allows additional (and separate) namespaces to be
created.
If your X server is a version that uses abstract sockets only (and UNIX
sockets in /tmp are disabled), you can re-enable UNIX sockets by adding
-listen unix to /etc/X11/xinit/xserverrc.
The OpenVPN example requires out-of-tree patches. Updated openvpn and ocproxy packages are available for Ubuntu 14.04 LTS and 16.04 LTS:
sudo -s
apt-get install software-properties-common
add-apt-repository --yes ppa:cernekee
apt-get update
apt-get install ocproxy openvpn
Original author: David Edmondson <[email protected]>
Current maintainer: Kevin Cernekee <[email protected]>
Project home page: https://github.com/cernekee/ocproxy
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent