Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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! Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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. Quote Link to comment
Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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 ?? Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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 Quote Link to comment
Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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? Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 Oh it definitely is if you got that result... Let me take another look at your files and logs. Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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. Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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 Quote Link to comment
Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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? Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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... Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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 Quote Link to comment
Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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. Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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. Quote Link to comment
Raidersan Posted May 20, 2014 Share Posted May 20, 2014 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. Quote Link to comment
Nezil Posted May 20, 2014 Author Share Posted May 20, 2014 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. Quote Link to comment
Raidersan Posted May 21, 2014 Share Posted May 21, 2014 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. Quote Link to comment
Nezil Posted May 21, 2014 Author Share Posted May 21, 2014 I'll take a look at this later today @Raidersan. Apologies for taking so long to get back to you, but I think we're very nearly there. Quote Link to comment
Raidersan Posted May 21, 2014 Share Posted May 21, 2014 No worries, I thought you were extremely fast to respond and your help is very much appreciated! Quote Link to comment
randall526 Posted May 22, 2014 Share Posted May 22, 2014 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 Quote Link to comment
Nezil Posted May 22, 2014 Author Share Posted May 22, 2014 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. Quote Link to comment
randall526 Posted May 22, 2014 Share Posted May 22, 2014 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!!!!! Quote Link to comment
randall526 Posted May 22, 2014 Share Posted May 22, 2014 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. Quote Link to comment
Nezil Posted May 22, 2014 Author Share Posted May 22, 2014 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. Quote Link to comment
Raidersan Posted May 22, 2014 Share Posted May 22, 2014 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? Quote Link to comment
Raidersan Posted May 23, 2014 Share Posted May 23, 2014 @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? Quote Link to comment
Recommended Posts
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.