OpenVPN only for Transmission data, and associated modifications

[Nezil]

@Nezil, a question about transmission binding to the tunnel.

I have notice that "bind-address-ipv4" & "bind-address-ipv6" get automatically populated by the deamon, but I now see that "bind-interface-device" also gets filled in automatically, to "tun0". I noticed that as I tried to experiment binding to eth0 instead to see if there was an issue with the tunnel itself, but then notice that the value in the JSON file gets overwritten with tun0 as soon as it is started.

Is that normal? What if you wanted to bind it to something else? How does it get the interface name?

 

I think the reason that the bind is failing, has to do with the routing that's set up.

 

The basic process is to allow the VPN provider to update your routing as normal, remove the default routes, add a new ip rule that directs packets originating from the VPN IP address to the 'vpn' routing table, and add a default route to this 'vpn' routing table.

 

I'm guessing that something is wrong with the routing tables, and that will prevent transmission from binding to it.

 

To answer your question re. the binding setting being overwritten, this is happening because the rc.transmission startup section looks to see the status of the ROUTE_VPN variable, and if set to 'yes', sets the settings.json parameters to route over tun0; if set to 'no', the settings.json parameters will be set not to bind to any interface and simply use the default routes. Any changes that you make to the settings.json file related to binding will always be overwritten as transmission starts up.

 

As an aside... this is exactly why I try to keep my plugins with as few options in the webUI as possible. Adding things to the webUI is nice, but can make things complicated and confusing for debugging and power users. I prefer to have as few settings as possible, and let a power use configure things in the application settings files as needed. As you can see previously in this post, I was asked to add this option, and I reluctantly did so. If you use the plugin version in my signature, the ROUTE_VPN option is not in that version, and neither is the option in the webUI. The rc.transmission script will also not update the settings.json file on each startup - this is the version that I use in fact.

 

Back to your issue...

 

Would you mind setting the 'verb' line in your .ovpn file to 'verb 3', starting the VPN and providing a capture of your openvpn.out file. This should show the routing commands that your provider is pushing to your machine on connection, and we can then go about modifying the route-up.sh file to match what's needed for your vpn provider.

 

It would be helpful if you could also let me know what the $route_vpn_gateway and $ifconfig_local variables are for this connection, but I'm sure I could work it out if you aren't able to do that.

 

For this test, it doesn't matter if you have a route-up.sh file called or not; I'm interested in what happens before any additional scripts are called.

[Raidersan]

It was already on verb 3 (and mute 3, not sure what that is!), so here it is

 

root@Tower:/mnt/cache/.apps/openvpn# cat /tmp/openvpn/openvpn.out 
Fri May 23 18:21:32 2014 OpenVPN 2.3.2 i486-slackware-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [iPv6] built on Jun 22 2013
Fri May 23 18:21:32 2014 WARNING: file '/mnt/cache/.apps/openvpn/password.txt' is group or others accessible
Fri May 23 18:21:32 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri May 23 18:21:32 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri May 23 18:21:32 2014 Socket Buffers: R=[163840->131072] S=[163840->131072]
Fri May 23 18:21:32 2014 UDPv4 link local: [undef]
Fri May 23 18:21:32 2014 UDPv4 link remote: [AF_INET]109.201.137.166:1194
Fri May 23 18:21:32 2014 TLS: Initial packet from [AF_INET]109.201.137.166:1194, sid=6916957a bd5e6020
Fri May 23 18:21:32 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri May 23 18:21:32 2014 VERIFY OK: depth=1, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=BTGuard CA, [email protected]
Fri May 23 18:21:32 2014 VERIFY OK: depth=0, C=DE, ST=Hesse-Nassau, L=Frankfurt, O=BTGuard, CN=server, [email protected]
Fri May 23 18:21:33 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri May 23 18:21:33 2014 NOTE: --mute triggered...
Fri May 23 18:21:33 2014 4 variation(s) on previous 3 message(s) suppressed by --mute
Fri May 23 18:21:33 2014 [server] Peer Connection Initiated with [AF_INET]109.201.137.166:1194
Fri May 23 18:21:35 2014 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri May 23 18:21:35 2014 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,redirect-gateway,route 10.10.10.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.10.214 10.10.10.213'
Fri May 23 18:21:35 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri May 23 18:21:35 2014 NOTE: --mute triggered...
Fri May 23 18:21:35 2014 3 variation(s) on previous 3 message(s) suppressed by --mute
Fri May 23 18:21:35 2014 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=30:85:a9:3c:b7:0a
Fri May 23 18:21:35 2014 TUN/TAP device tun0 opened
Fri May 23 18:21:35 2014 TUN/TAP TX queue length set to 100
Fri May 23 18:21:35 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri May 23 18:21:35 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Fri May 23 18:21:35 2014 /usr/sbin/ip addr add dev tun0 local 10.10.10.214 peer 10.10.10.213
Fri May 23 18:21:40 2014 /usr/sbin/ip route add 109.201.137.166/32 via 192.168.1.1
Fri May 23 18:21:40 2014 /usr/sbin/ip route del 0.0.0.0/0
Fri May 23 18:21:40 2014 /usr/sbin/ip route add 0.0.0.0/0 via 10.10.10.213
Fri May 23 18:21:40 2014 /usr/sbin/ip route add 10.10.10.1/32 via 10.10.10.213
------------------------------------------------------------------
default via 10.10.10.213 dev tun0 
10.10.10.1 via 10.10.10.213 dev tun0 
10.10.10.213 dev tun0  proto kernel  scope link  src 10.10.10.214 
109.201.137.166 via 192.168.1.1 dev eth0 
127.0.0.0/8 dev lo  scope link 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.251 
------------------------------------------------------------------
remove old rule:  /sbin/ip rule del from 10.10.10.142
route_vpn_gateway = 10.10.10.213
ifconfig_local = 10.10.10.214
RTNETLINK answers: No such process
RTNETLINK answers: No such process
ip rule add from 10.10.10.214 lookup vpn
ip route add default dev tun0 table vpn
Stopping transmission......OK
Starting transmission:  sudo -u transmission /usr/bin/transmission-daemon --port 9091 --config-dir /mnt/cache/.apps/transmission --pid-file /var/run/transmission/transmission.pid --logfile /var/log/transmission.log
1...Started OK

 

The 2 variables are:

 

route_vpn_gateway = 10.10.10.213

ifconfig_local          = 10.10.10.214

 

with ifconfig:

 

root@Tower:/mnt/cache/.apps/openvpn# ifconfig
eth0      Link encap:Ethernet  HWaddr 30:85:a9:3c:b7:0a  
          inet addr:192.168.1.251  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2576187 errors:0 dropped:637 overruns:0 frame:0
          TX packets:598054 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1959270037 (1.8 GiB)  TX bytes:78519743 (74.8 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:251 errors:0 dropped:0 overruns:0 frame:0
          TX packets:251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:298112 (291.1 KiB)  TX bytes:298112 (291.1 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.10.10.214  P-t-P:10.10.10.213  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:7262 (7.0 KiB)

[Nezil]

OK, so the commands that your VPN provider pushes to you are these (IP addresses shown with variable names):

/usr/sbin/ip link set dev tun0 up mtu 1500
/usr/sbin/ip addr add dev tun0 local 10.10.10.214 ($ifconfig_local) peer 10.10.10.213 ($route_vpn_gateway)
/usr/sbin/ip route add 109.201.137.166/32 via 192.168.1.1
/usr/sbin/ip route del 0.0.0.0/0
/usr/sbin/ip route add 0.0.0.0/0 via 10.10.10.213 ($route_vpn_gateway)
/usr/sbin/ip route add 10.10.10.1/32 via 10.10.10.213 ($route_vpn_gateway)

 

Which are quite different from those pushed by private internet access:

Thu May 22 12:59:17 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Thu May 22 12:59:17 2014 /usr/sbin/ip addr add dev tun0 local 10.172.1.6 ($ifconfig_local) peer 10.172.1.5 ($route_vpn_gateway)
Thu May 22 12:59:23 2014 /usr/sbin/ip route add 198.23.71.73/32 via 172.16.17.1
Thu May 22 12:59:23 2014 /usr/sbin/ip route add 0.0.0.0/1 via 10.172.1.5 ($route_vpn_gateway)
Thu May 22 12:59:23 2014 /usr/sbin/ip route add 128.0.0.0/1 via 10.172.1.5 ($route_vpn_gateway)
Thu May 22 12:59:23 2014 /usr/sbin/ip route add 10.172.1.1/32 via 10.172.1.5 ($route_vpn_gateway)

 

The route-up.sh must be set up to modify the routes pushed by each VPN provider, and the example that I gave, and you're using is based on the routes pushed by private internet access.

 

The major difference is that my VPN provider pushes an additional route (128.0.0.0/1 via $route_vpn_gateway), and this route is also deleted by the route-up.sh script.

 

The full list of routing commands in the route-up.sh is (IP addresses from your example added, as well as comments):

 

/sbin/ip rule del ${RULE} - This command removes any previous routing rules that would have been set up in previous sessions

/sbin/ip route del 128.0.0.0/1 via 10.10.10.213 ($route_vpn_gateway) - This command should fail on your system, because the route wasn't pushed by your VPN provider

/sbin/ip route del 0.0.0.0/1 via 10.10.10.213 ($route_vpn_gateway) - This command should work fine, removing the default route down the VPN tunnel

/sbin/ip rule add from 10.10.10.214 ($ifconfig_local) lookup vpn - This command should also work fine, creating a routing rule pointing packets from 10.10.10.214 to the 'vpn' routing table

/sbin/ip route add default dev tun0 ($dev) table vpn - This command should also work, creating a default route for packets applied to the 'vpn' table, routing them down the tun0 interface

 

I'm surprised that the current route-up.sh script doesn't work to be honest; the deleting of the 128.0.0.0 route will obviously fail, but that shouldn't cause any problems.

 

Could you comment out the script in the .ovpn file, and then manually run through each of the commands that I've shown above. It's important that when you do this, you also run the first command to remove the old rule; to find the rule that you're going to remove, first run this command:[pre]/sbin/ip rule | sed -n 's/.*\(from[ \t]*[0-9\.]*\).*vpn/\1/p'[/pre]and then use the output of that command to replace ${RULE} in the first command that you manually enter. You can do this before or your VPN has been restarted because it applies to the previous session.

 

Update:

I initially failed to notice that your VPN provider also issues an ip command to remove the existing default route, which mine does not, it only adds an additional one which appears to take precedence; that's this line:[pre]/usr/sbin/ip route del 0.0.0.0/0[/pre]This route will need to be added back in, or you'll have no default route for normal traffic after everything else is set up.

 

I'm going to take a stab at an updated route-up.sh script that might solve everything as follows:

 

#!/bin/sh

# Checks to see if there is an IP routing table named 'vpn', create if missing
if [ $(cat /etc/iproute2/rt_tables | grep vpn | wc -l) -eq 0 ]; then
        echo "100     vpn" >> /etc/iproute2/rt_tables
fi

echo "------------------------------------------------------------------"
/sbin/ip route show
echo "------------------------------------------------------------------"

# Remove any previous routes in the 'vpn' routing table
/sbin/ip rule | sed -n 's/.*\(from[ \t]*[0-9\.]*\).*vpn/\1/p' | while read RULE
do
echo "remove old rule:  /sbin/ip rule del ${RULE}"
/sbin/ip rule del ${RULE}
done

# Delete the default route setup when the OpenVPN tunnel was established
/sbin/ip route del 0.0.0.0/1 via ${route_vpn_gateway}

# Add back deleted default route
echo ip add ip route add 0.0.0.0/1 via 192.168.1.1 
/sbin/ip route add 0.0.0.0/1 via 192.168.1.1

# Add rule pointing to the vpn routing table
echo ip rule add from $ifconfig_local lookup vpn
/sbin/ip rule add from ${ifconfig_local} lookup vpn

# Add the route to direct all traffic using the the vpn routing table to the tunX interface
echo ip route add default dev ${dev} table vpn
/sbin/ip route add default dev ${dev} table vpn

# ntpd will use the tun0 interface, so block it
echo iptables -A OUTPUT -o ${dev} -p udp --dport 123 -j DROP
/usr/sbin/iptables -A OUTPUT -o ${dev} -p udp --dport 123 -j DROP

# Restart Transmission to load new tunnel local IP
/etc/rc.d/rc.transmission restart

exit 0

[randall526]

@Nezil, a question about transmission binding to the tunnel.

I have notice that "bind-address-ipv4" & "bind-address-ipv6" get automatically populated by the deamon, but I now see that "bind-interface-device" also gets filled in automatically, to "tun0". I noticed that as I tried to experiment binding to eth0 instead to see if there was an issue with the tunnel itself, but then notice that the value in the JSON file gets overwritten with tun0 as soon as it is started.

Is that normal? What if you wanted to bind it to something else? How does it get the interface name?

 

I think the reason that the bind is failing, has to do with the routing that's set up.

 

The basic process is to allow the VPN provider to update your routing as normal, remove the default routes, add a new ip rule that directs packets originating from the VPN IP address to the 'vpn' routing table, and add a default route to this 'vpn' routing table.

 

I'm guessing that something is wrong with the routing tables, and that will prevent transmission from binding to it.

 

To answer your question re. the binding setting being overwritten, this is happening because the rc.transmission startup section looks to see the status of the ROUTE_VPN variable, and if set to 'yes', sets the settings.json parameters to route over tun0; if set to 'no', the settings.json parameters will be set not to bind to any interface and simply use the default routes. Any changes that you make to the settings.json file related to binding will always be overwritten as transmission starts up.

 

As an aside... this is exactly why I try to keep my plugins with as few options in the webUI as possible. Adding things to the webUI is nice, but can make things complicated and confusing for debugging and power users. I prefer to have as few settings as possible, and let a power use configure things in the application settings files as needed. As you can see previously in this post, I was asked to add this option, and I reluctantly did so. If you use the plugin version in my signature, the ROUTE_VPN option is not in that version, and neither is the option in the webUI. The rc.transmission script will also not update the settings.json file on each startup - this is the version that I use in fact.

 

 

 

 

  This sounds right form what I've observed with my slightly different VPN setup as well.  I was able to get bind to tun0 interface to show up in the settings file by enabling the VPN route option in the web interface. I was attempting to bind to my eth1 interface, which kept getting over written.  I got the same results using the Transmission-2.82r14243-i486-4nr.plg version.  Now I'm left figuring out how to get this to work with my duel homed setup.  I prefer having my VPN in my router and I can't have two active tunnels to my provider or I would just set it up on unraid as well.

[Nezil]

@randall526, Try using version 1nr of the plugin; it's easier to customise for your requirements because there is fewer options in the web UI.

[Raidersan]

@NEZIL, I completely missed your post with the updated route-up, I picked up your next one and thought that was the one I got a notification for...

 

Anyway, just tried it, thank you very much !!, and it seems to work, but I still get error messages in the log, here it is:

 

[uPDATE] Ignore this for now, I believe it was working, now it it not, but I think that this is since I got bold after seeing it work, and tried to switch to route through eth0: to test it. So in summary I believe your solution works but the switching of interface bound to transmission fails to re-establish it. The log below therefore is probably not representative of the initial openvpn startup. Let me do a brand new test properly and will come back to you

 

root@Tower:~# cat /var/log/transmission.log 
[11:34:30.823] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:824)
[11:34:30.823] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1033)
[11:34:30.823] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:30.823] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:30.823] DHT Reusing old id (tr-dht.c:306)
[11:34:30.823] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[11:34:30.823] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[11:34:30.823] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:30.823] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:30.823] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[11:34:30.823] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[11:34:30.823] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:30.823] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:30.823] Transmission 2.82+ (14243) started (session.c:977)
[11:34:30.823] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[11:34:30.823] UDP Failed to set receive buffer: requested 4194304, got 327680 (tr-udp.c:78)
[11:34:30.823] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:83)
[11:34:30.823] UDP Failed to set send buffer: requested 1048576, got 327680 (tr-udp.c:89)
[11:34:30.823] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:94)
[11:34:30.823] Using settings from "/mnt/cache/.apps/transmission" (daemon.c:523)
[11:34:30.823] Saved "/mnt/cache/.apps/transmission/settings.json" (variant.c:1214)
[11:34:30.823] Saved pidfile "/var/run/transmission/transmission.pid" (daemon.c:535)
[11:34:30.823] Watching "/mnt/user/Downloads/Torrents/Todo" for new .torrent files (daemon.c:561)
[11:34:30.823] Using inotify to watch directory "/mnt/user/Downloads/Torrents/Todo" (watch.c:72)
[11:34:30.823] Found new .torrent file "MyHomeVideo.torrent" in watchdir "/mnt/user/Downloads/Torrents/Todo" (watch.c:91)
[11:34:30.823] Blocklist "blocklist.bin" contains 227852 entries (blocklist.c:113)
[11:34:30.823] Loaded 2 torrents (session.c:2252)
[11:34:30.823] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:70)
[11:34:30.823] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:70)
[11:34:38.828] Port Forwarding State changed from "Not forwarded" to "Starting" (port-forwarding.c:92)
[11:34:38.828] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:38.828] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:38.828] Searching for web interface file "/root/.local/share/transmission/web/index.html" (platform.c:405)
[11:34:38.828] Searching for web interface file "/usr/share/transmission/web/index.html" (platform.c:405)
[11:34:38.828] Port Forwarding (NAT-PMP) readnatpmpresponseorretry succeeded (0) (natpmp.c:70)
[11:34:38.828] Port Forwarding (NAT-PMP) Found public address "146.90.237.123" (natpmp.c:139)
[11:34:38.828] Port Forwarding (NAT-PMP) sendnewportmappingrequest succeeded (12) (natpmp.c:70)
[11:34:38.828] Port Forwarding (NAT-PMP) readnatpmpresponseorretry succeeded (0) (natpmp.c:70)
[11:34:38.828] Port Forwarding (NAT-PMP) Port 65000 forwarded successfully (natpmp.c:219)
[11:34:38.828] Port Forwarding State changed from "Starting" to "Forwarded" (port-forwarding.c:92)
[11:34:40.829] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:40.829] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:44.831] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:44.831] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:46.832] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:46.832] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:50.834] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:50.834] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:52.835] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:52.835] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:56.837] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:56.837] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:34:58.838] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:34:58.838] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:35:02.840] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:35:02.840] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:35:02.840] ipleak.net+torrent+detection Scrape error: Tracker gave HTTP response code 404 (Not Found) (announcer.c:1279)
[11:35:02.840] ipleak.net+torrent+detection Retrying scrape in 310 seconds. (announcer.c:1288)
[11:35:04.841] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:35:04.841] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:35:08.844] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:35:08.844] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:35:10.845] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[11:35:10.845] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[11:35:14.847] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)

 

my routes:

root@Tower:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router.asus.com 128.0.0.0       UG    0      0        0 eth0
default         10.10.10.133    0.0.0.0         UG    0      0        0 tun0
10.10.10.1      10.10.10.133    255.255.255.255 UGH   0      0        0 tun0
10.10.10.133    *               255.255.255.255 UH    0      0        0 tun0
109.201.137.163 router.asus.com 255.255.255.255 UGH   0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

[Raidersan]

Hi @Nezil,

 

Suspuscions confirmed, I did a clean restart with your new route-up script, and it does work, it does allow my torrents to connect, but I am still left with errors in the logs every 2 seconds, what should I do about this? here is the transmission log from startup:

 

root@Tower:~# cat /var/log/transmission.log 
[14:17:15.054] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:824)
[14:17:15.054] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1033)
[14:17:15.054] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:15.054] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:15.054] DHT Reusing old id (tr-dht.c:306)
[14:17:15.054] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[14:17:15.054] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[14:17:15.054] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:15.054] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:15.054] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[14:17:15.054] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[14:17:15.054] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:15.054] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:15.054] Transmission 2.82+ (14243) started (session.c:977)
[14:17:15.054] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[14:17:15.054] UDP Failed to set receive buffer: requested 4194304, got 327680 (tr-udp.c:78)
[14:17:15.054] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:83)
[14:17:15.054] UDP Failed to set send buffer: requested 1048576, got 327680 (tr-udp.c:89)
[14:17:15.054] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:94)
[14:17:15.054] Using settings from "/mnt/cache/.apps/transmission" (daemon.c:523)
[14:17:15.054] Saved "/mnt/cache/.apps/transmission/settings.json" (variant.c:1214)
[14:17:15.054] Saved pidfile "/var/run/transmission/transmission.pid" (daemon.c:535)
[14:17:15.054] Watching "/mnt/user/Downloads/Torrents/Todo" for new .torrent files (daemon.c:561)
[14:17:15.054] Using inotify to watch directory "/mnt/user/Downloads/Torrents/Todo" (watch.c:72)
[14:17:15.054] Found new .torrent file "Dad's Trip.torrent" in watchdir "/mnt/user/Downloads/Torrents/Todo" (watch.c:91)
[14:17:15.054] Blocklist "blocklist.bin" contains 227852 entries (blocklist.c:113)
[14:17:15.054] Loaded 4 torrents (session.c:2252)
[14:17:15.054] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:70)
[14:17:15.054] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:70)
[14:17:23.059] Port Forwarding State changed from "Not forwarded" to "Starting" (port-forwarding.c:92)
[14:17:23.059] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:23.059] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:23.059] Searching for web interface file "/root/.local/share/transmission/web/index.html" (platform.c:405)
[14:17:23.059] Searching for web interface file "/usr/share/transmission/web/index.html" (platform.c:405)
[14:17:23.059] Port Forwarding (NAT-PMP) readnatpmpresponseorretry succeeded (0) (natpmp.c:70)
[14:17:23.059] Port Forwarding (NAT-PMP) Found public address "146.90.237.123" (natpmp.c:139)
[14:17:23.059] Port Forwarding (NAT-PMP) sendnewportmappingrequest succeeded (12) (natpmp.c:70)
[14:17:23.059] Port Forwarding (NAT-PMP) readnatpmpresponseorretry succeeded (0) (natpmp.c:70)
[14:17:23.059] Port Forwarding (NAT-PMP) Port 59162 forwarded successfully (natpmp.c:219)
[14:17:23.059] Port Forwarding State changed from "Starting" to "Forwarded" (port-forwarding.c:92)
[14:17:23.059] ipleak.net+torrent+detection Tracker warning: "Detected IP:109.201.137.164, look http://ipleak.net for details." (torrent.c:573)
[14:17:25.060] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:25.060] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:29.062] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:29.062] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:31.063] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:31.063] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:33.064] ipleak.net+torrent+detection Scrape error: Tracker gave HTTP response code 404 (Not Found) (announcer.c:1279)
[14:17:33.064] ipleak.net+torrent+detection Retrying scrape in 20 seconds. (announcer.c:1288)
[14:17:35.065] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[14:17:35.065] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)
[14:17:37.067] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)

 

These 2 last messages are repeated every 2 seconds. I have not tested the unbinding of tun0: but this is very low priority for now.

I can see that my traffic is going through tun0:, certainly if top show traffic go through the 109 IP address from my VPN provider, so I am puzzled how that would work while getting all these errors???

 

BTW, a quick question, with the port forwarding working as listed in the log, do I still need a forwarding rule in my router? and if yes, I assume that the rule would have to forward to my vpn address, but this one changes all the time, so I thought I probably never needed this forward to start with, is that correct?

 

Also I have just noticed that my traffic coming in (I use Plex to watch my movies from my server to my hotel room) is not coming on eth0:. Being a network noob, I don't know if routing tables also need to be setup for incoming traffic. Certainly at the moment Plex cannot get to my library outside of my network as it did prior to the VPN setup.

 

Thanks Nezil!

[breakline]

wow awesome Nezil    that is a super write up you have done and can not wait to get started on this , I also have waited a long time for this,  I tried a bunch of of different guides and tutorials  to try accomplish this with pia and never felt safe that it was actually secure. Thank you for all your effort and time put into this.

[randall526]

So just to update, after trying several transmission client versions, I could never get the bind to interface to work.  My IP leak tests always revealed my public IP which was my default route for all traffic but not my only route available to the server.  I am currently in the middle of migrating unraid on to ESXi to solve this problem.  I will have transmission installed on a different Linux VM that has the VPN route as the default route.  I decided I was trying to do too much from unraid.  32GB Ram, Another SSD for my ESXi data store, and a SAS/SATA PCI-E adapter to do a PCI passthrough of HDD's to the unraid VM.  Looking forward to it.

[sureguy]

So just to update, after trying several transmission client versions, I could never get the bind to interface to work.  My IP leak tests always revealed my public IP which was my default route for all traffic but not my only route available to the server.  I am currently in the middle of migrating unraid on to ESXi to solve this problem.  I will have transmission installed on a different Linux VM that has the VPN route as the default route.  I decided I was trying to do too much from unraid.  32GB Ram, Another SSD for my ESXi data store, and a SAS/SATA PCI-E adapter to do a PCI passthrough of HDD's to the unraid VM.  Looking forward to it.

 

This is what I'm doing, it works well.  I have mine set up with some scripts so that transmission won't work unless the VPN is running.

 

Sent from a mobile device, sorry for any typos.

 

 

[randall526]

Nice, it sounds like this design has matured and the next logical stage to really start doing more with your server.  My VPN route is handled by my secondary router, in a separate subnet, behind my internet gateway router.  Fortunately, I have it all handled there and the connection will break if my VPN goes down.  I also understand this is a better, more secure method of setting up a VPN, rather than put the client and thus your internet edge on unraid.  I can also make that connection available to my other VM's in theory.  Doing some NFS mounts between VM's with a virtual only network and some jumbo packets should work nicely.