Nezil

@activ, I removed and re-created a new Docker, and everything is working great. I didn't spend much time debugging the previous instance of the Docker, so I'm not sure what I'd done to mess it up there, but the important thing is that the new one is working so I'm happy. Thanks for the work creating it! Me too, though I do admit that the UniFi controller UI Dashboard pane does look disappointingly empty without any swithes or routers in it. How often do you look at that though, once it's up and running...

It's late now, and I'm getting tired, but I'll try and do some additional debugging over the weekend. Regarding Ubiquiti... I had wanted to upgrade my WiFi for a while, because although I like the two Apple Airport Extremes that I had, I was having some odd behaviour switching between access points as I moved through the house, and neither of them supported 11ac. This need is what switched me on to Ubiquiti, because I'd heard their WiFi stuff was good. To be honest, I also REALLY like learning new things, and had wanted to dabble with VLAN for a while, so an EdgeRouter Lite and at lease one UAP-AC-PRO were ordered, along with an Engenius POE switch (to power the AP), and a couple of Netgear low cost managed switch for other parts of my house. It took quite a bit of time to set it all up, though simply replacing the AirPort Extreme Router functionality was very quick indeed, the firewall, VLAN and IPv6 stuff took a bit longer. Having said that though, maybe I'm crazy but I found it so much fun, and now that it's all done, I'm itching to do something similar and am looking doing an IP camera setup around our housing community! In summary, the Ubiquiti stuff has been great. A single UAP-AC-PRO has replaced two Airport Extremes and I get better coverage throughout my (3-floor town) house, and the EdgeRouter feels faster than the AirPort Extreme whilst providing me with greater functionality. I'd say go for it, but maybe get the EdgeRouter POE rather than the EdgeRouter Lite.

I recently upgraded to unRAID 6, and in doing so obviously lost all of my old plugins, including the Transmission one I created a couple of years ago that included OpenVPN support. Rather than try and re-write my old plugin into a Docker, I thought I'd check to see if there already was a Transmission Docker that fit my needs, and sure enough, thanks to @active, there is! The docker installed fine, and appears to connect to PIA using OpenVPN just like my old plugin did. I made a couple of changes like moving the Unfortunately, once the Docker starts up, it appears to have no connection to the outside world. I'm not sure if this is a problem with the way that my network and firewall router are set up, or if it's a configuration issue in the Docker. Would someone be able to help me debug this? The details of my network are: unRAID server running on VLAN 20 in my network, with an IPv4 subnet of 172.16.20.0/24 NAT Router (Ubiquiti EdgeRouter Lite) has a zone based firewall set to allow all outgoing to WAN, and allow established and related in from WAN. I tried opening up the firewall on the input, but this didn't help at all. I don't have any ports forwarded to the unRAID box currently, because I use a VPN to connect to the home network if I'm away and need access. I didn't need any ports forwarded with my Plugin before, but this is my thought on the most likely issue. Having said that, if all of the Transmission data is going over the OpenVPN link, there shouldn't be any need for local port forwarding I'd have thought?!? Thanks in advance for any help!

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

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

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.

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.

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.

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.

The reason that you're unable to create folders in the root of the share, is because the ownership of the folder on the unRAID system is probably root:root, with default permissions of drwxr-xr-x: I added the following command to my plugin to solve this problem: [pre]chgrp users /apps chmod g+w /apps [/pre]This changes the ownership to root:users, and makes the directory writable for members of the group users. The user that connects to the SMB share is a member of the users group, and is therefore able to write to the root of the share. By the way, the commands should be issued, I think, after the drive is mounted, rather than before. This might not be necessary, but that's how I did it.

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.

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.

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

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...

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