OpenVPN only for Transmission data, and associated modifications


Recommended Posts

Again a step forward. This time it seemed to be down to an entry in the settings.json file that I didn't have, peer-id-ttl-hours. As soon as I added it, it worked. So now at boot I have openvpn and transmission running, but...

 

I have an odd behaviour remaining. When I go the transmission plugin page on WebGUI, it takes minutes to come back. I assume it is failing to retrieve some values but no idea what it is struggling with

 

Also, when I realised the ipleak magnet was not working, I had a look at /var/log/transmission.log and found this:

[13:30:53.975] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[13:30:53.975] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bi
nd()'able (net.c:773)
[13:30:55.976] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[13:30:55.976] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bi
nd()'able (net.c:773)
[13:30:55.976] DHT Not saving nodes, DHT not ready (tr-dht.c:358)
[13:30:55.976] DHT Generating new id (tr-dht.c:310)
[13:30:55.976] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[13:30:55.976] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)

 

It looks like the interface binding is failing, or is it not?

Apologies for the amount of problems I am throwing at you, I am very keen to get this to work. The good news is that I am getting better at following how everything is happening. Many thanks!

 

UPDATE: I think I know what is failing the php, I see that both  ISP allocated Internet IP Address &

VPN tunnel Internet IP Address are empty, so it looks like the curl command fail has it does not get access to icanhazip, in fact I have no internet access from the terminal. here is my ifconfig output:

 

root@Tower:~# 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:27558 errors:0 dropped:1710 overruns:0 frame:0
          TX packets:23297 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3726169 (3.5 MiB)  TX bytes:9338062 (8.9 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:274 errors:0 dropped:0 overruns:0 frame:0
          TX packets:274 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:179248 (175.0 KiB)  TX bytes:179248 (175.0 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.54  P-t-P:10.10.10.53  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:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

My route-up.sh script doesn't seem happy, here is the output from the command line:

 

root@Tower:/mnt/cache/.apps/openvpn# ./route-up.sh 
------------------------------------------------------------------
default via 10.10.10.197 dev tun0 
10.10.10.1 via 10.10.10.197 dev tun0 
10.10.10.197 dev tun0  proto kernel  scope link  src 10.10.10.198 
109.201.137.167 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.198
Command line is not complete. Try option "help"
Command line is not complete. Try option "help"
ip rule add from lookup vpn
Error: an inet prefix is expected rather than "lookup".
ip route add default dev table vpn
Error: either "to" is duplicate, or "vpn" is a garbage.
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

 

 

Here is my openvpn.out

 

Tue May 20 15:00:33 2014 Initialization Sequence Completed
Tue May 20 15:00:33 2014 Bad LZO decompression header byte: 42
Tue May 20 15:00:41 2014 Bad LZO decompression header byte: 42
Tue May 20 15:00:51 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:01 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:11 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:21 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:31 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:41 2014 Bad LZO decompression header byte: 42
Tue May 20 15:01:51 2014 Bad LZO decompression header byte: 42
Tue May 20 15:02:02 2014 Bad LZO decompression header byte: 42
Tue May 20 15:02:11 2014 Bad LZO decompression header byte: 42
Tue May 20 15:02:21 2014 [server] Inactivity timeout (--ping-restart), restarting
Tue May 20 15:02:21 2014 SIGUSR1[soft,ping-restart] received, process restarting
Tue May 20 15:02:23 2014 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue May 20 15:02:23 2014 TCP/UDP: Preserving recently used remote address: [AF_INET]109.201.137.167:1194
Tue May 20 15:02:23 2014 UDPv4 link local: [undef]
Tue May 20 15:02:23 2014 UDPv4 link remote: [AF_INET]109.201.137.167:1194
Tue May 20 15:02:24 2014 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1541'
Tue May 20 15:02:24 2014 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Tue May 20 15:02:24 2014 [server] Peer Connection Initiated with [AF_INET]109.201.137.167:1194
Tue May 20 15:02:26 2014 Preserving previous TUN/TAP instance: tun0
Tue May 20 15:02:26 2014 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
Tue May 20 15:02:26 2014 /usr/sbin/ip addr del dev tun0 local 10.10.10.18 peer 10.10.10.17
Tue May 20 15:02:27 2014 TUN/TAP device tun0 opened
Tue May 20 15:02:27 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue May 20 15:02:27 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Tue May 20 15:02:27 2014 /usr/sbin/ip addr add dev tun0 local 10.10.10.194 peer 10.10.10.193
------------------------------------------------------------------
default via 10.10.10.193 dev tun0 
10.10.10.1 via 10.10.10.193 dev tun0 
10.10.10.193 dev tun0  proto kernel  scope link  src 10.10.10.194 
109.201.137.167 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.18
RTNETLINK answers: No such process
RTNETLINK answers: No such process
ip rule add from 10.10.10.194 lookup vpn
ip route add default dev tun0 table vpn
Stopping transmission.../etc/rc.d/rc.transmission: line 79: kill: (21005) - No such process
...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
Tue May 20 15:02:38 2014 Initialization Sequence Completed
Tue May 20 15:02:38 2014 Bad LZO decompression header byte: 42
Tue May 20 15:02:46 2014 Bad LZO decompression header byte: 42
Tue May 20 15:02:56 2014 Bad LZO decompression header byte: 42
Tue May 20 15:03:06 2014 Bad LZO decompression header byte: 42

Something is fishy but that is where my knowledge stops!

Link to comment
  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

Good work getting this far @Raidersan!

 

You're correct that the unRAID settings page taking a long time to load would be as a result of lookup of IP address. To be honest, I wasn't sure about putting these into the webUI, but thought it was useful (when everything is working correctly!).

 

I think the most likely issue is that your route-up.sh script is at fault, or your .ovpn file that calls it. You cannot run the route-up.sh script directly, because when it is run, certain variables are passed to it that are required for commands to work correctly; the only way that route-up.sh will work is when it's called by openvpn.

 

Although you've provided quite a lot of terminal output, you've not given me copies of the two files that I need... Could you paste up the contents of your .ovpn file, and your route-up.sh file please.

Link to comment

I thought that must be the case, that the env variables would only be provided when in context...

Ok so here is OVPN:

 

root@Tower:~# cat /mnt/cache/.apps/openvpn/btguard.ovpn 
#default privateinternetaccess ovpn lines
client
proto udp
dev tun
remote vpn.btguard.com 1194
resolv-retry infinite
nobind
persist-key
persist-remote-ip
persist-tun
tls-client
remote-cert-tls server
# auth-user-pass
comp-lzo
verb 1
reneg-sec 0

# Provide full paths to certificate and passwords files
ca btguard.ca.crt
auth-user-pass /mnt/cache/.apps/openvpn/password.txt


# Change routing behaviour
script-security 3
route-delay 5
route-up "/mnt/cache/.apps/openvpn/route-up.sh"

# Set location of Status Log
status /tmp/openvpn/openvpn-status.log

# Add code to re-connect if link drops
keepalive 10 60

 

and route-up.sh

 

root@Tower:~# cat /mnt/cache/.apps/openvpn/route-up.sh 
#!/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 128.0.0.0/1 via ${route_vpn_gateway}
/sbin/ip route del 0.0.0.0/1 via ${route_vpn_gateway}

# Add routes 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

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

exit 0

 

What silly thing have I forgotten now ??  ;)

Link to comment

Well those files both look OK to me.

 

One thing that is concerning is that your openvpn.out log shows a couple of lines at the point of one of the ip commands:

[pre]RTNETLINK answers: No such process[/pre]I would only expect this to happen if you weren't actually running my custom kernel.

 

Could you check if you are indeed running the custom kernel? To do this, issue the following two commands and tell me what you see:

[pre]ip rule list[/pre]On my system, with my vpn running, I see the following:

0:	from all lookup local 
32765:	from 10.112.1.6 lookup vpn 
32766:	from all lookup main 
32767:	from all lookup default 

 

If my custom kernel is not running, you would see this:

RTNETLINK answers: Operation not supported
Dump terminated

 

In case this is the problem, you need to make sure that my custom kernel files are being linked in the syslinux.cfg file. Since my custom kernel files are called bzimaged and bzrootd, it's not as simple as just putting the files in the root folder on the flash drive. You could rename them bzimage and bzroot and then reboot, but you'd probably want to backup the original bzimage and bzroot files before you do that.

 

In my case, I've set my custom kernel files as the default, but retained the original files as options that I could select at boot. My syslinux.cfg file therefore looks like this:

default /syslinux/menu.c32
menu title Lime Technology
prompt 0
timeout 50
label unRAID OS Custom Kernel
  menu default
  kernel /bzimaged
  append initrd=/bzrootd
label unRAID OS Custom Kernel (no plugins)
  kernel /bzimaged
  append initrd=/bzrootd unraidsafemode
label unRAID OS Standard
  kernel /bzimage
  append initrd=/bzroot
label unRAID OS Standard (no plugins)
  kernel /bzimage
  append initrd=/bzroot unraidsafemode
label Memtest86+
  kernel /memtest

Link to comment

yep, I get the same:

 

root@Tower:~# ip rule list
0:	from all lookup local 
32765:	from 10.10.10.230 lookup vpn 
32766:	from all lookup main 
32767:	from all lookup default 

 

I did go the brave route by rename bzimage and bzroot though.

So I am pretty sure it is your kernel. Any other way to make sure?

Link to comment

Are you absolutely sure that the .ovpn file you pasted is the one being called? I can see that the route-up.sh is definately being called correctly, but part of the problem is that your vpn provider is not giving your unRAID machine a correct routing table for itself.

 

I can also see that the .ovpn file you attached is resulting in quite a verbose openvpn.out file, but it is only set to verb 1.

 

I'm going to have a look at what a standard settings file from your provider should look like, because this might help.

 

This an excerpt from my openvpn.out log file with verb 3 set, which shows the full routing when the VPN connects initially, before any modifications are made by the route-up.sh script:

Tue May 20 11:13:11 2014 ROUTE_GATEWAY 172.16.17.1/255.255.255.0 IFACE=eth0 HWADDR=d0:27:88:59:8f:8b
Tue May 20 11:13:11 2014 TUN/TAP device tun0 opened
Tue May 20 11:13:11 2014 TUN/TAP TX queue length set to 100
Tue May 20 11:13:11 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue May 20 11:13:11 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Tue May 20 11:13:11 2014 /usr/sbin/ip addr add dev tun0 local 10.151.1.6 peer 10.151.1.5
Tue May 20 11:13:16 2014 /usr/sbin/ip route add 198.23.71.90/32 via 172.16.17.1
Tue May 20 11:13:16 2014 /usr/sbin/ip route add 0.0.0.0/1 via 10.151.1.5
Tue May 20 11:13:16 2014 /usr/sbin/ip route add 128.0.0.0/1 via 10.151.1.5
Tue May 20 11:13:16 2014 /usr/sbin/ip route add 10.151.1.1/32 via 10.151.1.5
------------------------------------------------------------------
0.0.0.0/1 via 10.151.1.5 dev tun0 
default via 172.16.17.1 dev eth0  metric 1 
10.151.1.1 via 10.151.1.5 dev tun0 
10.151.1.5 dev tun0  proto kernel  scope link  src 10.151.1.6 
127.0.0.0/8 dev lo  scope link 
128.0.0.0/1 via 10.151.1.5 dev tun0 
172.16.17.0/24 dev eth0  proto kernel  scope link  src 172.16.17.3 
198.23.71.90 via 172.16.17.1 dev eth0 
------------------------------------------------------------------

 

As you can see, four additional ip route commands are issued by openvpn immediately after connection, your openvpn.out log doesn't show any of these, and I believe that is the source of your problems.

 

There is an option that can be put in the .ovpn file that stops this from happening, and that might be what's causing this behaviour (route-nopull), which is why I'm questioning if you really are using the correct .ovpn file.

Link to comment

Your current .ovpn file looks like this (so you say):

#default privateinternetaccess ovpn lines
client
proto udp
dev tun
remote vpn.btguard.com 1194
resolv-retry infinite
nobind
persist-key
persist-remote-ip
persist-tun
tls-client
remote-cert-tls server
# auth-user-pass
comp-lzo
verb 1
reneg-sec 0

# Provide full paths to certificate and passwords files
ca btguard.ca.crt
auth-user-pass /mnt/cache/.apps/openvpn/password.txt


# Change routing behaviour
script-security 3
route-delay 5
route-up "/mnt/cache/.apps/openvpn/route-up.sh"

# Set location of Status Log
status /tmp/openvpn/openvpn-status.log

# Add code to re-connect if link drops
keepalive 10 60

 

The default recommended btguard .ovpn file looks like this:

client
dev tun
proto udp
remote vpn.btguard.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/btguard.ca.crt
verb 3
mute 3
auth-user-pass
mute-replay-warnings
float
reneg-sec 0

 

I'd therefore modify it to look like this:

# Default btguard configuration
client
dev tun
proto udp
remote vpn.btguard.com 1194
resolv-retry infinite
nobind

# Change routing behaviour
script-security 3
route-delay 5
route-up "/mnt/cache/.apps/openvpn/route-up.sh"

# Continue default btguard configuration
persist-key
persist-tun
# ca /etc/openvpn/btguard.ca.crt
verb 3
mute 3
# auth-user-pass
# mute-replay-warnings
float
reneg-sec 0

# Provide full paths to certificate and passwords files
ca /mnt/cache/.apps/openvpn/btguard.ca.crt
auth-user-pass /mnt/cache/.apps/openvpn/password.txt

# Set location of Status Log
status /tmp/openvpn/openvpn-status.log

# Add code to re-connect if link drops
keepalive 10 60

Link to comment

Hehe!! very good, I copied your version of the ovpn and that works. But....

 

... in the plugin page, both ISP allocated Internet IP Address and VPN tunnel Internet IP Address show the same address, the vpn one.

Also, I tried to switch the Route Traffic Through VPN Tunnel parameter to No, but that has broken some config again as the start script does the 1...2...3... before failing:

 

root@Tower:/mnt/cache/.apps/transmission# /etc/rc.d/rc.transmission start
/etc/rc.d/rc.transmission: line 30: [: ==: unary operator expected
Starting transmission:  sudo -u transmission /usr/bin/transmission-daemon --port  --config-dir /mnt/cache/.apps/transmission --pid-file /var/run/transmission/transmission.pid --logfile /var/log/transmission.log
1...2...3...4...5...6...7...8...9...10...11...
Transmission.pid not created for some reason

 

I see that my transmission.cfg has been overwritten:

 

root@Tower:/mnt/cache/.apps/transmission# cat /boot/config/plugins/transmission/transmission.cfg 
# transmission configuration
SERVICE="enable"
CONFIGDIR="/mnt/cache/.apps/transmission"
PORT=""

 

It really needs a port and a ROUTE_VPN parameter as well. Does you script overwrite this file?

Link to comment

You're correct that the configuration file should have PORT and ROUTE_VPN parameters included, and transmission will of course fail to load without a port defined.

 

It's strange that these appear to be getting wiped for some reason... let me check the plugin one more time...

Link to comment

My STUPID mistake, I guess I rushed getting the plugins up for the previous poster, and didn't bother to reboot my own system to check. I'd updated my rc.transmission file for testing, and hadn't put all of the changes into the plugin.

 

Here is an updated file; you shouldn't have to reboot to get it to work, just delete your /etc/rc.d/rc.transmission file, as well as your /boot/config/plugins/transmission folder, then run:

[pre]installplg /boot/config/plugins/Transmission-2.82r14243-i486-4nr.plg[/pre]Download the updated plugin from here: https://dl.dropboxusercontent.com/s/c3f84xqs4c8ksr5/Transmission-2.82r14243-i486-4nr.plg

Link to comment

That was quick... and effective! ok switching now works, but I have a suspicion something is wrong

See my previous post about both addresses being the same, here is my experiment:

 

root@Tower:/boot/config/plugins/transmission# curl -s --interface tun0 http://www.icanhazip.com
109.201.137.162
root@Tower:/boot/config/plugins/transmission# curl -s http://www.icanhazip.com
109.201.137.162
root@Tower:/boot/config/plugins/transmission# curl -s --interface eth0 http://www.icanhazip.com
^C

 

The last one doesn't come back, I had to CTRL-C it. I assume that the second command should have gone to eth0, no? But apparently is uses tun0 by default, and the eth0 interface doesn't work.

Link to comment

You're right, something is wrong with the routing.

 

Can you show me the output of the following commands, I'm showing mine for reference:

root@unRAID:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.17.1     0.0.0.0         UG    1      0        0 eth0
10.151.1.1      10.151.1.5      255.255.255.255 UGH   0      0        0 tun0
10.151.1.5      *               255.255.255.255 UH    0      0        0 tun0
loopback        *               255.0.0.0       U     0      0        0 lo
172.16.17.0     *               255.255.255.0   U     0      0        0 eth0
198.23.71.90-st 172.16.17.1     255.255.255.255 UGH   0      0        0 eth0

 

root@unRAID:~# ip route show
default via 172.16.17.1 dev eth0  metric 1 
10.151.1.1 via 10.151.1.5 dev tun0 
10.151.1.5 dev tun0  proto kernel  scope link  src 10.151.1.6 
127.0.0.0/8 dev lo  scope link 
172.16.17.0/24 dev eth0  proto kernel  scope link  src 172.16.17.3 
198.23.71.90 via 172.16.17.1 dev eth0 

 

I think the next thing to do would be to manually walk through the stages of the route-up.sh script and see where it's stumbling. It looks like the default route for eth0 is not being set up correctly.

Link to comment

absolutely right, my default is on tun0:

 

root@Tower:/boot/config/plugins/transmission# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.10.10.249    0.0.0.0         UG    0      0        0 tun0
10.10.10.1      10.10.10.249    255.255.255.255 UGH   0      0        0 tun0
10.10.10.249    *               255.255.255.255 UH    0      0        0 tun0
109.201.137.162 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

 

root@Tower:/boot/config/plugins/transmission# ip route show
default via 10.10.10.249 dev tun0 
10.10.10.1 via 10.10.10.249 dev tun0 
10.10.10.249 dev tun0  proto kernel  scope link  src 10.10.10.250 
109.201.137.162 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 

 

Let me see if I can make sense of the script and diagnose it.

Link to comment

Thanks, I have a meeting I need to go to now, so it would be great if you're able to diagnose it yourself.

 

If it helps, the output of those commands on my system with vpn disconnected is as follows:

root@unRAID:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.17.1     0.0.0.0         UG    1      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
172.16.17.0     *               255.255.255.0   U     0      0        0 eth0

root@unRAID:~# ip route show
default via 172.16.17.1 dev eth0  metric 1 
127.0.0.0/8 dev lo  scope link 
172.16.17.0/24 dev eth0  proto kernel  scope link  src 172.16.17.3 

 

And with route-up.sh disabled, so the default routing from my vpn provider only:

root@unRAID:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.152.1.5      128.0.0.0       UG    0      0        0 tun0
default         172.16.17.1     0.0.0.0         UG    1      0        0 eth0
10.152.1.1      10.152.1.5      255.255.255.255 UGH   0      0        0 tun0
10.152.1.5      *               255.255.255.255 UH    0      0        0 tun0
loopback        *               255.0.0.0       U     0      0        0 lo
128.0.0.0       10.152.1.5      128.0.0.0       UG    0      0        0 tun0
172.16.17.0     *               255.255.255.0   U     0      0        0 eth0
198.23.103.88-s 172.16.17.1     255.255.255.255 UGH   0      0        0 eth0

root@unRAID:~# ip route show
0.0.0.0/1 via 10.152.1.5 dev tun0 
default via 172.16.17.1 dev eth0  metric 1 
10.152.1.1 via 10.152.1.5 dev tun0 
10.152.1.5 dev tun0  proto kernel  scope link  src 10.152.1.6 
127.0.0.0/8 dev lo  scope link 
128.0.0.0/1 via 10.152.1.5 dev tun0 
172.16.17.0/24 dev eth0  proto kernel  scope link  src 172.16.17.3 
198.23.103.88 via 172.16.17.1 dev eth0 

 

This should give you some indication of what is created and deleted by the route-up.sh. There is some things left over in the routing actually, because the route-up.sh removes some things before it adds others. I don't have time now to get a clean, route-up.sh disabled output I'm afraid.

Link to comment

I have added a few lines to echo the env variables, but it is now clear that the problem lies with the following commands:

 

/sbin/ip route del 128.0.0.0/1 via ${route_vpn_gateway}
/sbin/ip route del 0.0.0.0/1 via ${route_vpn_gateway}

 

route_vpn_gateway = 10.10.10.13

These return the line

RTNETLINK answers: No such process

and I believe this is where the default routing is stuck to the VPN

I commented out my route-up option in the OVPN file and got the following to compare to yours

 

NO VPN

root@Tower:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router.asus.com 0.0.0.0         UG    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

root@Tower:~# ip route show
default 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 

 

WITH VPN

root@Tower:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
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.166 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

root@Tower:~# ip route show
default via 10.10.10.133 dev tun0 
10.10.10.1 via 10.10.10.133 dev tun0 
10.10.10.133 dev tun0  proto kernel  scope link  src 10.10.10.134 
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 

 

I see that your openvpn config gives you 2 default routes, one to tun0, and one to eth0. Mine doesn't. And I wonder if that does cause the ip route del command to fail. I am dangerously lacking in routing knowledge but it sort of make sense that it would not allow removing the only default gateway rule. I know from reading forums that the ip rule add fails with the same message when it doesn't recognise the network being added. What do you think? How could I modify the OVPN file to give me a double default route like yours?

 

[uPDATE]

I tried to manually delete the default gateway, and with the IP address (as in they script), it fails, but this works:

ip route del default
ip route add default via 192.168.1.1

 

I end up with both curl commands (in your plugin page) now giving me the 2 different IP addresses. How would you suggest I modify the script to make it work in my setup?

 

Also, looking now at the transmission log (we are moving!!), I see a weird message every 2 secs, do you have the same?

[12:10:09.085] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)
[12:10:09.085] isAvailableBindAddress::assuming that the address (may otherwise at other times) be bind()'able (net.c:773)

 

Looking through my settings.json file, i see the 2 following lines

    "bind-address-ipv4": "10.10.10.134",.
    "bind-address-ipv6": "fd7f:54eb:9f51:be9a:1:2:3:4",

 

I assume this gets automatically updated by transmission? The IP address seems correct for tun0, so not sure why it logs an error, and it certainly fails to connect to anything. Could it be my manual routing that has created havoc?

curl from the command line seem to show that both eth0 and tun0 are alive and well and eth0 takes precedence.

Link to comment

Sorry to hijack a productive conversation, great thread and much appreciated work to all.

 

  I'm am trying to achieve the same results of routing only transmission through VPN, though through a slightly different approach.

 

My server is currently dual homed with two adapters, one adapter eth0 is on the main network on my LAN that shares plex with all the clients and has the the standard internet gateway connected to the modem.

 

The other network connects to a DD-WRT router setup with VPN to overplay VPN with it's WAN IP on my LAN network and pointed at my internet gateway for a default gateway.

 

I had to add this to my go file.

 

ifconfig eth1 192.168.1.90 netmask 255.255.255.0

route add default gw 192.168.1.1 metric 5 eth1

 

Route Table

kernel IP routing table

Destination    Gateway        Genmask        Flags Metric Ref    Use Iface

default        192.168.2.1    0.0.0.0        UG    1      0        0 eth0

default        192.168.1.1    0.0.0.0        UG    5      0        0 eth1

loopback        *              255.0.0.0      U    0      0        0 lo

192.168.1.0    *              255.255.255.0  U    0      0        0 eth1

192.168.2.0    *              255.255.255.0  U    0      0        0 eth0

 

192.168.2.0 is on my normal LAN through eth0

 

Ideally all of my normal traffic goes through the lower metric route unless explicitly bound to an interface such as transmission should be able to do.

 

I don't think I need a custom kernel or anything for my setup.

 

 

 

My issue is two fold:

 

1.  I am running Transmission-2.82r14243-i486-3nr.plg and can't get my settings in settings.json to stick.  Editing while transmission is running does nothing, and restarting transmission over writes the file with defaults every-time just after I edited it.  I have the config directory pointed at /mnt/cache/.transmission/conf.  It's picking up on my pre downloaded blocklist there just fine, however getting it to bind to an interface never takes and is over written when the service is bounced.

 

2.  Port forwarding, transmission requires a port forward to work properly which always breaks on my VPN, regardless of what my router VPN gateway port fowards are set to.  If I understand the issue correctly, my true Internet edge is my VPN address assigned by my VPN provider, further out on the net somewhere.  I have no control over how that gateway is configured.  Has anyone gotten their port forwards to work?  My understanding is my setup with a DD-WRT router set to use a VPN would have the same issue running the OpenVPN client on unraid as far as port forwards are concerned.  Has anyone gotten this to work properly?

 

Thanks much

Link to comment

Sorry to hijack a productive conversation, great thread and much appreciated work to all.

 

1.  I am running Transmission-2.82r14243-i486-3nr.plg and can't get my settings in settings.json to stick.  Editing while transmission is running does nothing, and restarting transmission over writes the file with defaults every-time just after I edited it.  I have the config directory pointed at /mnt/cache/.transmission/conf.  It's picking up on my pre downloaded blocklist there just fine, however getting it to bind to an interface never takes and is over written when the service is bounced.

 

2.  Port forwarding, transmission requires a port forward to work properly which always breaks on my VPN, regardless of what my router VPN gateway port fowards are set to.  If I understand the issue correctly, my true Internet edge is my VPN address assigned by my VPN provider, further out on the net somewhere.  I have no control over how that gateway is configured.  Has anyone gotten their port forwards to work?  My understanding is my setup with a DD-WRT router set to use a VPN would have the same issue running the OpenVPN client on unraid as far as port forwards are concerned.  Has anyone gotten this to work properly?

 

Thanks much

 

No problem with hijacking the conversation, you post is totally relevant.

 

To quickly answer question 2, no I am not aware of any way to have port forwarding working for torrents over a vpn link. I was able to get this to work using Private Internet Access' own software on the Mac, but only on a few (I believe it was Cananda and Netherlands) server addresses, and even then, the port changes every hour or so, requiring constant changes to your torrent client.

 

Private Internet Access did have some forum discussion about a scripted way to identify the port, and then adjust your torrent client when a change is detected, but I never managed to get this to work myself.

 

Having said that, I don't really think that port forwarding is necessary any more. I have downloaded a lot using the setup described in this thread (I'm talking around 1TB in the last few months) and I've never had a problem. My seed ratio is not fantastic, but it's also not 0. With popular torrents it approaches and sometimes exceeds a ratio of 1, and if I left torrents active I'm sure that the ratio would simply continue to increase.

 

In short, I'm not sure that it's important, and I'm certainly not worried about it.

 

For question 1, I'm far from a routing expert, so I can't help too much if that is what's causing your problems. Have you checked the Transmission log to see if it's throwing up any errors relating to the loading of the settings.json file?

 

You might also want to check that you don't have any remnants of other Transmission plugins hanging around that might be messing with your configuration like @Raidersan did.

 

I do know that any changes directly to the settings.json file must be done while Transmission is NOT running. If it's running, they'll be overwritten on exit with whatever was there when Transmission started, along with any changes made in the UI. You must first stop, then edit the file, then restart.

Link to comment

Ive herd there are some premier VPN providers that allow you to configure port forwarding on their end of the VPN tunnel but I don't have any experience with this.  I feared this may be the case.

 

  Transmission does indeed work with out portforwarding, however I've noticed my downloads get substantially cut by over 50% in my experience thus far.

 

I've gone through like 10 transmission clients over the years, 3 from reading this thread alone.  I thought I cleaned it all up, but it very well may be possible I have something lingering.  Starting transmission through the main web gui does indeed over write the file every time though.

 

Thanks for the reply!!!!!

Link to comment

garrr... cleaned out anything that looked like it may be remanent of other transmission installs, packages from unmenu and any other left over directories, to install clean and did a reboot.  Still can't get the file settings to stick.  The settings I can configure in the web mgt interface stick fine, however there is nowhere in there to set a bind to interface there.  Every time I start transmission, the bind setting gets lost...

 

Wonder if I should be on a different plug in version.  On Transmission-2.82r14243-i486-3nr.plg now  Transmission-2.82r14243-i486-4nr.plg failed to start for me.

 

 

Link to comment

I'm pretty sure that version 3 has a problem where it does not save the ROUTE-VPN option in the configuration file. Version 3 should definitely not be used.

 

If version 4 is not working, let's look at debugging that one. To start with, remove all trace of any plugin, including the /boot/config/plugins/transmission folder, and restart with version 4 in place. If that doesn't work, we'll need to dig deeper, but @Raidersan is using that one with no issues as far as we know.

Link to comment

I am on version 4, but I did have to add the ROUTE_VPN entry myself.

What I did:

1) backup /boot/config/plugins/transmission and whatever location transmission uses to store settings (settings.json)

2) delete them

3) Ensure there is not a Transmission plugin trailing anywhere else in the boot DIR

4) with Nezil's Transmission plugin version 4 in /boot/config/plugins/, reboot

5) Change /boot/config/plugins/transmission.cfg to have the ROUTE_VPN=yes and ensure the other params are ok.

6) restart Transmission

7) Setup transmission through Webgui

 

The binding sticks in the config file (remember to stop transmission before making the change), but the binding fails for me. For some reason transmission fails to bind and torrents just sit there as if they were paused, unable to connect to anything. I have run out of idea about that one, my routing is sort of sorted now, albeit with an unattractive manual intervention, but I do not think routing is the root cause for transmission to fail to bind to the tunnel. I am hoping somebody will have a better idea than me at some point!

 

BTW @Nezil, is there a debug level that can be set on the transmission deamon so that it can be more verbose that the current one? I can only find one for lib curl but I suspect this only related to torrent scraping and not the initial setup. When I switch it on I actually see little more, probably because it fails to make contact to anything. But I do see a new line in my log, probably I missed it before:

 

[08:43:35.347] Bind socket to device 'tun0' error: 'Operation not permitted' (1) (net.c:243)
[08:43:35.347] isAvailableBindAddress::bind() probe gave an unhandled error code 22 (net.c:772)

 

Could it be that the transmission process started by user transmission does not have the rights to bind to a root-owned device?

 

[uPDATE] Changed the startup script to start the deamon as root, makes no difference, still failing on the "failure to bind to the tunnel" error - Anybody with a suggestion?

 

Link to comment

@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?

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.