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:
Code:
ip link add dev macvlan0 link eth0 type macvlan
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.
Code:
iptables -t mangle -A PREROUTING -i macvlan0 -j MARK --set-mark 1
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.
Code:
10 default_direct
11 default_tun2socks
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:
Code:
ip route add table default_direct 0.0.0.0/0 via <your_real_default_gateway_eg_ISP>
ip route add table default_tun2socks 0.0.0.0/0 via <tun2socks gateway, e.g. 10.0.0.2>
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.
Code:
ip rule add pref 40000 fwmark 1 lookup default_tun2socks
ip rule add pref 40001 lookup default_direct
Your ip rules should now look like that:
Code:
# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
40000: from all fwmark 0x1 lookup default_tun2socks
40001: from all lookup default_direct
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:
Code:
badvpn-udpgw --listen-addr 127.0.0.1:7300
and point tun2socks (which runs on the local Linux router) to it:
Code:
badvpn-tun2socks ... --udpgw-remote-server-addr 127.0.0.1:7300
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.