jmbrnt

Yeah that's kind of what I was thinking, if the performance of a raw HTTP download is just as crappy as the torrent, then the problem is narrowed down to the VPN, or as you say, the hub. L2TP tunnel to AA.net.uk for a tenner a month?

One thing to try would be downloading a big binary file from a well hosted location, like an Ubuntu ISO (not torrent). This one is hosted at Oxford uni, so should be pretty fast http://mirror.ox.ac.uk/sites/releases.ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso I would wget it from inside Binhex's container and check the speed of the PIA tunnel against something that _should_ blast on Virgin Media You'll need to add wget first: pacman -S wget then wget http://mirror.ox.ac.uk/sites/releases.ubuntu.com/releases/bionic/ubuntu-18.04.2-desktop-amd64.iso (from inside the container's shell) ---- I just tried it and installing wget failed.. You could use a browser and the Privoxy function of the container, or the PIA application on your desktop etc to do the same test.

So you're in modem mode, passing through to what?

I have to say Sweden seems better than Switzerland, but my uploads are still messed up and my ratios are all taking a major hit compared to "no vpn". NORD was simple to set up, but as it doesn't support port forwarding at all you might find it not so great for uploads. Downloads however, fine. I have used both but honestly I think PIA was a waste of money and I'll just risk it with no VPN

I seem to have absolutley terrible performance with PIA in Sweden/Switzerland. Rubbish compared to NordVPN for downloads, and despite ports being forwarded correctly (as reported by the tracker) - still just crap upload too. Miserable would describe it FWIW I used a Virgin Superhub 3 as a passthrough device (PPPoE) to a Mikrotik router that cost about £100 and it absolutely flew, line rate on anything I liked, as long as I wasn't using PIA (obviously their infrastructure comes into play there).

Magic, and just like that the problem seems to be (slowly) resolving on the tracker. Thanks for the support, I'm making a donation

OK cool - I was still having troubles with the tracker saying the port was actually open in that mode so I wasn't sure. With that out of the way - your container *should* just do the rest for me, right? 😉 Thanks again!

Hi - I have a bit of a curly problem - apologies if it's been solved here before, I have searched and searched but have failed. I have a tracker that I connect to with binhex-delugevpn (and it's great!) - but this particular tracker only allows 4 IP addresses to connect, and changing IP requires a login from that IP over HTTPS (sigh), which I can do with Lynx from inside the binhex-delugevpn shell (after installing lynx). PIA allows for port forwarding from a set of their servers, but unfortunatley they have 84 servers behind the DNS name for X.privateinternetaccess.com (where X is the port-forwarding enabled server(s)). When I restart the deluge container, I get a new IP - which breaks my tracker - not ideal! I have changed the .ovpn file I use so that "remote" points to a particular IP, rather than a DNS name, but this throws up errors in the supervisord.log file (saying I'm not using a recognised port-forwarding server). I then added a static entry in the deluge container's /etc/hosts file, pointing X.privateinternetaccess.com to a specific IP, which my tracker would accept - however this seems not to be as static as I had hoped - arch seems to overwrite the IP with one that it resolves when the container restarts. Is there a nice way to keep using the port-forwarding PIA server, but only a specific IP? Thanks

Physically, the packets leaving your docker, on your unraid server do run through your home router - however the beauty of tunneling (VPN) is that extra padding is added on the outside of your normal packets, encapsulating what you are sending/receiving with the tunnel provider (this extra padding also has its own ports).. This is what gives you the additional security - it also extends a logical connection from the VPN endpoint (in this case, the Docker container) and the other endpoint (PIA's machine elsewhere). This can be thought of as a single long piece of network cable, with no interfering routers/firewalls in the way. Thinking of it like this, the PIA endpoint is the router for this connection, so the port-forwarding needs to be done there. A packet comes in from some source with port 55588.. PIA allows forwarding of that packet on to you, so it hits your docker and Deluge with that src port.. If your provider doesn't allow forwarding, the port number is changed and as a result Deluge doesn't perform as well.. This is the same as if you were doing the port forwarding on your router for another service.. Except that when using VPN, your router has no idea what ports you're exchanging with the outside world.. All it sees is encrypted packets heading off toward PIA's IP (and coming back).

I've previously had great success with Unblock.us from New Zealand - don't remember it being expensive.

And the answer to that is "not yet". I am OK with the speeds I get and have a year left on my subscription

Well.. I have a 100M FTTH connection and I can hit 9.8MB/s using the Switzerland node I have picked (having just tested an Ubuntu ISO). However, it tends to hover around 1-3MB/s I'm connected via a 'Powerline' ethernet adaptor, which I suspect is introducing some loss. My recent house move has caused my speeds to deteriorate as well. Any TCP transmission is going to get hammered by packet loss, so I don't think blaming NordVPN for the speeds I get is entirely fair. However, I tend to automate any downloads I have, so I'm not sitting in front of the TV waiting for things to complete - in my use-case the speeds I get are more than enough. If you like I can switch to a UK based endpoint and have a go, but as I'm in the UK the test won't be fair either

Son of a.... Thanks mr hex!

Thanks - it's much the same, the problem stanza seems to keep repeating.. Here's 15 mins or so supervisord_longer.txt

Sorry to bump this, but I really have no idea what's wrong

As soon as I can get the bloody thing started again I'll be stoked

It helps to do it wrong 700 times and then pop up on forums trying to explain it to others.. Some of these guys are way ahead. As wgstarks says, you can also give deluge (via gui) a torrent file. This also downloads the .torrent file via your VPN as it's all done in the Docker container.

When you set up deluge (by editing the docker via the Unraid GUI) - you will have set up a /data path.. That path will represent a folder on your unraid filesystem where deluge will download things.. For me, it's this: So, if I ssh onto my Unraid box, and type 'cd /mnt/user/incoming' I end up in that folder. Deluge can 'see' this folder, so you can put a .torrent file in there and add it - or you can setup a subfolder to hold torrent files and tell Deluge to 'watch' that folder, then it will pickup automatically. I do that, so I grab a .torrent file on my Windows machine and paste it into that mounted 'new_torrent' folder (which lives on the Unraid box, in reality) - and hey presto, it downloads for me

Try a big public torrent like Ubuntu http://releases.ubuntu.com/17.10/ubuntu-17.10.1-desktop-amd64.iso.torrent

I think you just need to make sure port-forwarding is enabled in your delugevpn config. This should not be done on your router, this is being tunnelled through you router, so it won't see the port to be forwarded. There is a setting called 'strict port forwarding' or similar, that needs to be set to yes.

Argh, sorry - I thought I had debug on. Re-attached. Nord I have a year of subscription left and have been using them at near-linespeed for over a year in this setup - so even if it's slow I'm keen to keep using it - at least until I can get delugevpn to load again! Thanks for your time supervisord_debug.log

I upgraded to Unraid 6.4, and since then, the following problem.. I am using NordVPN (so, custom). - delugevpn GUI stopped working. Not sure if deluge itself was still working under the hood - tried to fix it, failed.. deleted from unraid - re-added via template, same issue persists (but when VPN disabled, all my settings/torrents still there) - notice that newly installed one has fewer/different layout of 'custom' VPN variables than the older previously working one.. Have replicated them manually - still doesn't work - seems to loop around telling me my credentials have incorrect permissions (these are set by docker..) Log attached - quite a weird one! Happy to cough up beers for a solution supervisord.log

You could change your PIA password and reboot the container - then try and pull a linux iso torrent - that won't work unless your PIA tunnel is up - which it won't be as the password has changed.

Ah, duh. Thanks. I notice however that when I go to dnsleaktest.com I'm not protected, and it shows up my ISP's IP address (despite icanhazip.com showing the VPN address). I have set the DNS of the container to dns.watch addresses.. Anyway - could it be that privoxy doesn't support HTTPS and dnsleaktest forces HTTPS?

So far, mostly so good for me. I configured the containers to use my VPN provider, all good. Torrents download just fine (testing on debian torrents). What I can't get going, is privoxy. It appears to start up OK - but I get this error when I access it on port 8118: "Invalid header received from client" When I look in the log, I see nothing for port 8118, suggesting IPTables isn't allowing it through - or something else funky is going on. I searched for that error string, to no avail. Any idea what it might be? I've attached a sanitised log (and paid you beer money) help_please.txt