strike

Looks like it's not getting a valid IP from the tunnel. It fails a bunch of times then it's able to get a valid IP one time from what I can see, then it "thinks" it's getting a valid IP but it's really the IP from the tun adapter (I think). Anyway if you were able to get a valid IP from the tunnel it won't do you any good, as private trackers won't work at all and with public trackers you'll get slow speed due to the fact that tigervpn doesn't support port forwarding. As far as I can tell anyway. You'd be better off trying AirVPN or PIA.

You'll also need to change the host port on the container to 80, right now it's 81, if you didn't change it already.

Got it, thanks!

So I finally got around to updating this container. I've been following this thread and expected the container to throw errors and not start until I added the HTTPVAL variable. But it didn't, it started fine with no errors. But maybe this is because my cert is not yet due for renewal? It says so in the log anyway. Or am I missing something here? ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... using keys found in /config/keys [cont-init.d] 30-keygen: exited 0. [cont-init.d] 50-config: executing... 2048 bit DH parameters present SUBDOMAINS entered, processing Only subdomains, no URL in cert Sub-domains processed are: -d subdomain.domain.com E-mail address entered: [email protected] <-------------------------------------------------> <-------------------------------------------------> cronjob running on Sun Jan 21 04:48:45 CET 2018 Running certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log ------------------------------------------------------------------------------- Processing /etc/letsencrypt/renewal/subdomain.domain.com.conf ------------------------------------------------------------------------------- Cert not yet due for renewal ------------------------------------------------------------------------------- The following certs are not due for renewal yet: /etc/letsencrypt/live/subdomain.domain.com/fullchain.pem (skipped) No renewals were attempted. No hooks were run. ------------------------------------------------------------------------------- [cont-init.d] 50-config: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. Server ready

I just set up my deluge docker with it's own IP and it's working great. It's not on an different NIC tho.. But I don't see why that would make a difference, it's just br0 vs br1. But then again I'm not a network guru of any kind.. I did have problems connecting to radarr and medusa at first, but then I remembered they where configured to use privoxy on the old IP. Once I updated the IP it was all good.

If 192.168.0.11 is your unraid IP, then your Lan_Network in the delugevpn container setting is wrong. You have 1.0/24 at the end you have redacted the rest. So you shound't even be able to get to the webui. But maybe you have changed that after, clearly you must have since you say you can get to the webui.

You have redacted the part I wanted to see... What do you have as the hostname? And it never says in the log that you have tried to connect to 8118. If 192.168.0.11 is your unraid IP address, then that is what the hostname should say. Do not include http(s) or anything else. If you have a working vpn tunnel then all you need to do in radarr is to enable the proxy and put in the correct hostname /port and of course configure radarr to connect with deluge. I also suggest that you move this to the sonarr / radarr thread as this is not a delugevpn issue but sonarr / radarr configuration issue. I have radarr working fine with privoxy .

So what does the log say with 8118 instead of 8113? Radarr I have, could you post a sreenshot of the proxy settings in the general tab in radarr?

First of all just run one of the containers at least until you get everything to work. And do I understand you correctly that it is just privoxy you have have problems with? You have a working tunnel on the delugevpn container and are able to reach the webui with the vpn enabled? You didn't answer my question why your sonarr logs say it tries to connect to port 8113? It should be 8118, are you sure you have set up the proxy in sonarr correctly? Screenshot?

I don't use sonarr so I don't know if I can help, but are you using sabnzbdvpn and delugevpn at the same time? If so, are privoxy enabled on both? Why does it say it tries to connect to port 8113 in the logs? Privoxy runs on 8118 by default

Have you checked the sonarr log, what does it say? I doubt anyone can help without logs.

Last update of this container was 6 days ago, the medusa devs issued a new release on the 26th 3 days ago and linuxserver.io updates all their containers once a week on Fridays IIRC. So there you have it.

This container includes privoxy, with that you can route your browser through the vpn tunnel. Just enable privoxy in the container settings and point your browser's proxy settings to "unraidIP:8118"

None. Connect to one of the endpoints that support port forwarding, that's it. And enable strict port forwarding in the container settings

If you drop the .crt and the .pem file in the same dir as the .ovpn file I think you should be good to go You'll find them in the same .zip from PIA. You should also change your password ASAP. Remember to remove it from the log next time Edit: reported your post to remove the logfile

Hmm.. Then I have no clue, can't spot anything obvious in the log either.

You mentioned you're using chrome, do you use an extention or do you use the proxy setting in the OS? If you are using an extention have you tried a diffrent one? I remember a another user having problems with a chrome proxy extention, and IIRC he solved it by using a different extention. Or maybe configure your OS settings to use the proxy. Please also post your entire supervisord.log from you delugevpn appdata folder, maybe we can spot something there. Edit: And yeah, please enable debug logging in the deluge container

Have you tried to nuke your docker image and pull down all the containers again? I Remember having this issue once and I think that solved it for me

In sickrage you must include http:// looking at your SR log it looks like you just have defined 192.168.0.101:8118

First, you need to add a path in you docker template and point it to where your log is. Then you need to add a new jail to ../fail2ban/jail.local and just point the logpath to the path you just created. That’s about it. You might wanna adjust the bantime, findtime and maxretry too. The default bantime is just 10 min which is too low IMO. If you use nginx auth there's already jails in place to monitor your nginx log so you don't need to add that. Edit: I forgot that you'll need to add a filter to ../fail2ban/filter.d Just call it minio.conf or something.This is my filter for my emby server: # Fail2Ban filter for emby # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = emby-server failregex = Info HttpServer: HTTP Response 401 to <HOST>.*authenticatebyname Info HttpServer: HTTP Response 500 to <HOST>.*mediabrowser/Users/None ignoreregex = # DEV Notes: # # Matching on http 401 with a trailing url including 'authenticatebyname' to catch incorrect passwords # Matching on http 500 with a trailing url including 'mediabrowser/Users/None' to catch incorrect usernames # # Author: [email protected]

Yeah, and also the .crt and .pem files, forgot about those.. I always do since I use AirVPN I only need the .ovpn file.. :P

Just replace the .ovpn file you have in your /config/openvpn folder with one from the zip, I always recommend the Netherlands one. Then restart the container. You shouldn't need to change anything else in the template as of recent updates the container pulls all the needed info from the .ovpn file.

I don't use sonarr, but I had the same problem with radarr the first time I set up this container. Turned out I forgot to set the "URL Base" in the webui settings for radarr.

@krobson17 Or this zip which connects over TCP 443, https://www.privateinternetaccess.com/openvpn/openvpn-ip-tcp.zip if @binhex's zip doesn't do the trick ( it uses TCP 502 rather than 443). But both are definitely worth a try, I found that trying different ports and protocols made a huge difference in speed. Unfortunately, some ISP's applies caps/blocks on some ports so if it works you know why. Edit: Pasted the wrong link, fixed..

Edit ../fail2ban/action.d/iptables-common.conf and comment out the last section so it looks like this: [Init?family=inet6] # Option: blocktype (ipv6) # Note: This is what the action does with rules. This can be any jump target # as per the iptables man page (section 8). Common values are DROP # REJECT, REJECT --reject-with icmp6-port-unreachable # Values: STRING #blocktype = REJECT --reject-with icmp6-port-unreachable # Option: iptables (ipv6) # Notes.: Actual command to be executed, including common to all calls options # Values: STRING #iptables = ip6tables <lockingopt> Restart the container