Hello all,

I have a shell box at a hosting provider with a dedicated IP address and root access. I wanted to setup a Socks5 proxy + SSL so that I can use it for secure tunneling of traffic to the Internet via the box when on, say, public Wifi etc.

I configured Dante on the server and setup Stunnel to allow me to connect to it, and everything works properly - the connection works and is SSL encrypted.

Now what I'm wondering is if there's any way to add UDP support to this picture. I have a few apps that can use Socks5 to proxy UDP connections. In most cases, I cannot set a different IP/port for the UDP packets. This means that since I'm Stunneling and thus connecting to localhost, I'd somehow need to have something listening on localhost on the UDP port that matches the stunner TCP port and forwards this UDP traffic somehow to the Dante server.

So, is there any way short of doing a full-blown VPN that would allow me to tunnel UDP traffic to my Dante proxy? Obviously we would really like this to be over some form of encryption. (SSL is not necessarily mandatory but I don't know of any sort of "UDP Stunnel" solution.)

Advice greatly appreciated!

F

My tun2socks program might be useful, though I'm not sure how well it would integrate with your existing setup.

In short, tun2socks runs on the client and implements a virtual network interface that forwards all outgoing TCP connections through a SOCKS5 server. This is used to force all apps to go through the proxy, behind their back, and you don't have to (and shouldn't) configure proxy servers in the apps. It has some support for UDP, which works by you starting a forwarder daemon (udpgw) on the server, and having tun2socks connect to this daemon through the SOCKS link (which is TCP).

In this setup, when tun2socks receives a UDP packet from the OS, it sends it to the udpgw daemon on the server, which then directly sends the packet into the wild (without going through a proxy), and it also sends back any replies.

This may actually do exactly what I need. I will probably need to do a bit of network restructuring but it should be workable.

Right now, I have Dante running in client mode on my Linux router, and in server mode on the remote shell. So, if I want to SOCKS-ify a connection, I point that application to use the SOCKS server at, say, 192.168.1.1:8999.

To integrate this, I'm guessing I could run the BadVPN/OpenVPN suite on the Linux router, and it would then create another interface that I could either manually or via DHCP direct the clients I want SOCKS'ed to use it as its default gateway?

Like, suppose I have 192.168.1.1 as the main router, but then I create 192.168.1.2. And any machine that uses 192.168.1.2 as its default gateway will get SOCKS'ed, but those that use 192.168.1.1 won't.

Is this something I can do?

Or will I need to end up setting up two separate physical LAN segments - one SOCKSed, one not. (Or maybe multihoming might work - assigning the internal LAN interface a second IP like 192.168.2.1 and then using that subnet for SOCKSed clients?)

Thanks again, looks like I have some networking fun ahead of me.

F

Could you explain your setup in more detail? I don't know about how Dante works, and what "server mode" and "client mode" means.

As far as I get it, you have a SOCKS server running on the remote machine, but you use stunnel, so that all incoming SOCKS connections go through SSL. Then, on your Linux router, you have another SOCKS server running; this one accepts plain incoming connections, and just forwards them to the remote SOCKS server, wrapping the SOCKS connection in SSL. Is that right?

In this scenario, you could start tun2socks on the Linux router, and point it to the local SOCKS server. You can control what goes into this tun2socks's socksifying interface via routing rules. I think that your idea with different gateways is great; however, it won't work straight away.

The problem is that when you tell a client to use some default gateway, it will resolve the MAC address of the router, and the frames it sends will only be directed to this MAC address; the destination IP address will be the real destination. In other words, if you assign two different IP addresses to the router's local interface (say eth0) it has absolutely no idea which gateway IP address you were using. This means that if the router wants to know which gateway IP address you were using, each gateway IP would have to be located at a different MAC address.

This is in fact possible with Linux. So, assume you already have one, the regular, local IP address, which will route directly. You have to create a new virtual interface for the second address, which will be bound to eth0, but will have a different MAC address:

This will make a macvlan0 interface with a random MAC address, to which you can assign the second IP address. This address will be reachable from your LAN, like your first address, but the catch is that it will be associated with a different MAC address. In simple terms, it will be as if you had two physical network cards plugged into the same switch, but without actually using two physical cards.

Now that the two gateway addresses have different MAC addresses, the router can use the destination MAC to figure out which gateway address they were sent to. We now use iptables to mark those incoming packets that came in via macvlan0; we will use these marks later in routing policies.

First, remove any existing default gateways from the "main" routing table (and make sure they don't get added there again). Instead, we will add default routes into separate routing tables. So, assign names for two new routing tables you will be using. Do this by adding a line to /etc/iproute2/rt_tables with an unused number. E.g.

Routing table default_direct will contain a single default route for direct routing. Table default_tun2socks will contain a single default route for routing into tun2socks. Add these routes:

Now we can use ip rules to choose which of those two routing tables will be used, based on the firewall mark. Note that the 'pref' is significant, as it makes sure that the rule applies only after the local and main routing tables have already been consulted, and nothing matched there.

Your ip rules should now look like that:

This should be it. Any to-be-forwarded packet that was sent using the IP of macvlan0 as a gateway will be matched and marked by the iptables rule we added earlier. When the time comes to determine where it should be routed, the routing rules will be consulted one after another. Assuming the destination address wasn't local or directly attached, either the tun2socks route or direct default route will be used, based on whether the packet was marked.

As far as UDP is concerned, it should suffice to start the udpgw program on the remote server:

and point tun2socks (which runs on the local Linux router) to it:

Yes, that's a local address, and it's right, because tun2socks connects to udpgw via the local SOCKS proxy, which goes through the remote SOCKS proxy, so the address you specify here is relative to the remote server. Make sure the remote SOCKS server allows connecting to this local address.