SSH SOCKS proxy support

[diffuser 0]

It'd be great to have support for SSH DynamicForward

that opens a local SOCKS proxy that allows application-specific tunneling setups,

in case tunneling all traffic is not desired.

On a related note, support for RemoteForward would be also nice to have.

 

[zhang888 1066]

You can do the SSH request with a rule in iptables. A setup that will forward your desired destination port via the openvpn tunnel.

Remote port forwarding is in https://airvpn.org/ports

[diffuser 0]

To clarify, I meant SSH DynamicForward through the AirVPN servers, i.e. instead of running OpenVPN over SSH and tunnel all traffic,

only use SSH and set up specific applications to use the local SOCKS proxy provided by SSH.

[zhang888 1066]

No that is not an option. This is technically impossible to implement it server-side as well, to enforce the 3 sessions limit with this kind of setup.

You can use Tor for that.

[diffuser 0]

For the record, this can be achieved by running a stand-alone socks server with the outgoing interface set to the openvpn tunnel interface. Also, adding route-noexec to the openvpn config prevents openvpn from changing the routing table, if desired.

[NaDre 157]

It'd be great to have support for SSH DynamicForward

that opens a local SOCKS proxy that allows application-specific tunneling setups,

in case tunneling all traffic is not desired.

...

 

You can set this up yourself. Set up a VirtualBox or VMware player virtual machine, with a "bridged" NIC (so other devices at home can access it) with Linux (e.g. Ubuntu server) on it, and run OpenVPN on that.

 

The SQUID HTTP proxy may work better for browsing. If you are using Windows you can run SQUID without a VM. See:

 

https://airvpn.org/topic/9491-guide-to-setting-up-vpn-just-for-torrenting-on-windows/?p=49046

 

...

On a related note, support for RemoteForward would be also nice to have.

 

Don't understand what you mean.

[sir_trackmenot 4]

Sorry for the late bump. I only comment because I was seeing if this was possible. I was just looking to use the VPN and couldn't be bothered getting OpenVPN working on my laptop. I was hoping I could just configure the SOCKS tunnel and be up and running. The SOCKS tunnel has some advantages for normal browsing use. As far as I can tell when you tell Firefox to use SOCKS and to tunnel remote DNS there are no leaks if the tunnel should stop for any reason. That's fairly compelling. It's TCP only and I don't know if it provides much protection for torrenting though.

 

No that is not an option. This is technically impossible to implement it server-side as well, to enforce the 3 sessions limit with this kind of setup.

You can use Tor for that.

 

That's not entirely true. It would require some server-side development to be sure, but it could be made to work. Look to gitosis/gitolite to see how you might do it. I don't even think it would be very difficult SSH-side.

 

Everyone logs onto a single user (git@myserver) with private key authentication. The ssh_config is configured to require key authentication for that user and to block running any programs other than a specific gitolite shim.

 

The administrator uploads each users' SSH public key to the authorized_keys file for git@myserver and sets the key comment to the users' real identity. Gitolite can use the key comment to identify the user after they have authenticated. The key (or user in ssh_config) is restricted to running a single application - gitolite in that example. The users cannot get a raw shell.

 

AirVPN could do similar with a simple shim like gitolite. Once the user's identity is established that program can access the central (?) database and log an established connection for the user. If there are too many connections it can simply terminate and cause SSH to hang up the connection. The administrator in this case could be the AirVPN web interface, where the user can upload their SSH public key. The web interface could easily update the global authorized_keys file. Some periodic sync process could have each VPN server fetch the authorized keys file from the central place, presuming that's how the AirVPN infrastructure is configured.

 

I imagine that the majority of the pain is implementing the web interface in the client area and also removing/disabling public keys for users that have expired.

 

Just some food for thought anyway.