Binding software to tunnel interface

[moonbuggy]

Hi,

I'm having trouble with using a tunnel as an output interface for various pieces of software. I'm probably just noobing hard and missing something simple, but I'd appreciate any advice.

I'm running an RT-AC3200 with asus-merlin 378.56_2 and entware-ng. Slightly simplified from the real situation, you can assume I have the following interfaces: eth0 (unencrypted WAN), tun11 (VPN), br0 (LAN).

My routing is set up so that eth0 is the default route for the router, everything else on the LAN subnet goes through tun11 (with a few exceptions for services that block traffic from VPN/proxy IPs). This is all set up through the web GUI and works just fine.

My end goal is to run srelay and have a SOCKS proxy sitting on the router that directs traffic down tun11, but this is where my problem arises. For simplicity, I'm going to describe it in terms of a curl command, because that's what I've been using to test and I believe the problem is the same in each case.

Basically, when I specify a non-default interface as an output interface for software on the router, the software fails to connect. It works fine on the default interface, and both interfaces work when appropriate ip routes are set up - as in, all traffic from the router works going through eth0 and all traffic on the LAN works going through tun11.

This is what happens when I try curl commands on the router (and the same happens with srelay with the appropriate parameters):

admin@RT-AC3200:/tmp/home/root$ curl -v --interface eth0 http://icanhazip.com
* About to connect() to icanhazip.com port 80 (#0)
*   Trying 64.182.208.185... Local Interface eth0 is ip $WAN_INTERFACE_IP using address family 2
* Local port: 0
* connected
* Connected to icanhazip.com (64.182.208.185) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.7 (arm-unknown-linux-gnu) libcurl/7.21.7 OpenSSL/1.0.2d zlib/1.2.5
> Host: icanhazip.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 21 Dec 2015 16:26:00 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 15
< Connection: close
< X-RTFM: Learn about this site at http://bit.ly/icanhazip-faq and don't abuse the service
< X-BECOME-A-RACKER: If you're reading this, apply here: http://rackertalent.com/
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET
<
$WAN_IP
* Closing connection #0

admin@RT-AC3200:/tmp/home/root$ curl -v --interface tun11 http://icanhazip.com
* About to connect() to icanhazip.com port 80 (#0)
*   Trying 64.182.208.184... Local Interface tun11 is ip $VPN_INTERFACE_IP using address family 2
* Local port: 0
* Connection timed out
*   Trying 64.182.208.185... Local Interface tun11 is ip $VPN_INTERFACE_IP using address family 2
* Local port: 0
* Connection timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

I've replaced potentially identifying IPs with variables. $WAN_INTERFACE_IP is the same as my public $WAN_IP, but the $VPN_INTERFACE_IP is not the same as my public $VPN_IP. I'm not sure if this is relevant or not but thought I should mention it.

As I say, I'm probably just noobing hard and missing something, but I'm not sure why this isn't working. I assume there's something I need to do in iptables to make this go, but I've been unsuccessful in trying to find a specific solution on the web, and trying various semi-random things that I don't fully understand hasn't solved the problem either.

Could anyone ease my headache and tell me what I need to do to make this work?

 

[moonbuggy]

Never mind. I seem to have finally solved the problem. Gotta set up a route for the $VPN_INTERFACE_IP if you expect packets to go anywhere.

Who'd have thunk it? Turns out I did just noob my way into missing something obvious.