OpenVPN tunnels not supported?

[domohawk]

I'm probably just dumb, but I cannot seem to get microsocks to work with my openvpn tunnel interfaces.

I create a vpn tunnel:

openvpn --config "$OVPN_FILE" --dev tun_vpn --pull-filter ignore redirect-gateway --auth-user-pass "$AUTH_FILE" --daemon "$DAEMON"

ifconfig:

tun_vpn: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.0.1  netmask 255.255.0.0  destination 10.1.0.1

start microsocks:

microsocks -i 0.0.0.0 -p 1080 -u $USER -P $PASS -b 10.1.0.1 -w 127.0.0.1,192.168.1.10,::1

No microsocks errors, but curl/firefox just hang. with -b 0.0.0.0 or -b 192.168.1.10 works just fine with same curl command.

I've tried with 2 different vpn providers, and both openvpn tunnels have connectivity with a program that can bind to the tunnel device (tun_vpn) directly.

[domohawk]

Actually I'm going to guess tun interfaces are not supported. I ran into the same issue with bwrap/firejail. Just now some reading, it seems like tun interfaces are L3 (as opposed to tap which is L2. Not that I'm clear on the difference). If that's the case and this setup just isn't possible, an error message would be helpful.

I just want to run specific apps on specific (tun) interfaces without setting my box's default gateway or running a full container. Why can't cgroups do this?

[rofl0r]

microsocks uses regular libc functions for networking, and these assume that routes are properly set up. the need to do this is why i'm not very fond of how VPN solutions currently work. i've suggested in one of those products that they provide a socks mode, where a socks4a/5 daemon is started instead of messing around with tun/tap devices and routes. that would also remove the need for elevated privileges. while technically possible, nobody has come around yet and picked up my idea to provide an actual implementation though.

[domohawk]

So the linux routing stack is out of my depth, but it sounds like it is technically impossible to socks5 a tun device? Kinda sad. One of my best parts of linux is the "everything is a file" abstraction, it would have been nice that binding to an outgoing IP address was just as seamless.

[domohawk]

A fast-fail error would be nice here for microsocks though

[rofl0r]

A fast-fail error would be nice here for microsocks though

and how would that work ? parsing your route tables to see whether the specified binding ip is an outgoing route? or just refuse to start if a /dev/tun entry is detected? seems ridiculous.

[domohawk]

Like I said, linux routing tables are out of my depth. But yea, refusing to start if it's a tun device would be a much better user experience than opening a ticket on GitHub.

[domohawk]

#79 works for me