[Support] binhex - SABnzbdVPN


1337 posts in this topic Last Reply

Recommended Posts

On 2/26/2021 at 6:02 AM, jademonkee said:

So what do we change to get Sonarr and Radarr to work via Privoxy if it's not the ADDITIONAL_PORTS var?

 

EDIT: I got Sonarr and Radarr to work again by going to (in Sonarr and Radarr) Settings > Config > General > Proxy and adding my server's IP in "Ignore addresses" ("Bypass proxy for local addresses" was already checked, and I left it so).

Additionally, in SABnzbd, if you have under General > Security a "List of local network ranges" defined, be sure to add the ranges for your Sonarr and Radarr Dockers, as well as your LAN IP range (or just leave it blank). Frustratingly, if you add it as CIDR notation, you will be locked out of the UI, so add it in the following format:

192.168.1.,172.17.0.

(the second range covers both my Sonarr and Radarr Dockers)

So lets say someone did add as CIDR and was locked out, what would you suggest to fix?  ACK!

Link to post
  • Replies 1.3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

hi guys, spotted the issue regards dos2unix.sh and corrected it, image now  building, should be done in around an hour.. then pull and you should be back up and running.

ok guys, spotted the issue. it was a legacy bug that the additional logging picked up causing the exit of sabnzbd (even though it was running). sadly i cannot currently build a new image with the fix

The new image has built so if you now pull down latest it should work as expected Sent from my EML-L29 using Tapatalk

Posted Images

4 hours ago, haredw said:

So lets say someone did add as CIDR and was locked out, what would you suggest to fix?  ACK!

 

I did the same thing. I went into appdata for sabnzb, edited the sabnzbd.ini file and removed what I entered in the "local_ranges" part. Saved, restarted container and back in.

Link to post
On 3/4/2021 at 9:30 AM, binhex said:

I would love to see a log demonstrating this bug as I'm not aware of it, please attach the log if you can.

Sent from my CLT-L09 using Tapatalk
 

 

I tried to reproduce this, but the nslookup of the vpn server ip does not return the root dns server IP address any more. I assume I have no control over that as it is the behavior of one of the DNS servers in $NAME_SERVERS responding. you should be able to reproduce it if you find a name server and the right options so that it would return also the root name server addresses in addition to the vpn server ip address. You will then see that the way you parse that answer, that it will not only grab the vpn server remote ip address but also the ip addresses of the root name servers and put them all into $VPN_REMOTE_SERVER. Each of the IPs in $VPN_REMOTE_SERVER will then be prepended with "-remote" and appended to the openvpn command. Sorry I can't do more for you at this point.

 

Link to post

Not sure if this has been discussed. But I have all my containers working with the new versions by adding additional_ports. My problem is getting those containers to talk to containers outside of the VPN.  I use Sonarr and plex. Currently Sonarr is function as it should and routing through sabnzbvpn But I have a connection setup in sonaar to tell plex when to update. I have tried the host ip and Local host.  I assume the IPtables no longer allow this. My plex is setup as host, Sab as bridge and sonaar connecting through sab. 

Link to post
Not sure if this has been discussed. But I have all my containers working with the new versions by adding additional_ports. My problem is getting those containers to talk to containers outside of the VPN.  I use Sonarr and plex. Currently Sonarr is function as it should and routing through sabnzbvpn But I have a connection setup in sonaar to tell plex when to update. I have tried the host ip and Local host.  I assume the IPtables no longer allow this. My plex is setup as host, Sab as bridge and sonaar connecting through sab. 
See q27 in the recommended post.

Sent from my CLT-L09 using Tapatalk

Link to post

I am not having any luck getting my *arr's to connect to SABnzb. All of my dockers have their own IP, nothing shares IP with unraid. All of the *arr's go through the qbittorrent docker with vpn and privoxy. I can hit all webui's no problem and all openvpn's are connected successfully. Indexers all work and torrents work with all the *arr's. The only thing that isn't working is the *arr's can't see the SABnzb Download Client (they did before updates). Any ideas beyond what is in the FAQ? I have tried every combination that I can think of that is listed in the FAQ and not having any success. Thanks!

Link to post

So I was able to get Sonarr to work properly by following the instructions on Q26 of the recommended post and adding my local server to the ignored addresses field in Sonarr.  So far so good.  Unfortunately I've been procrastinating in my move from couchpotato to Radarr.  In the settings for couchpotato, there doesn't seem to be an "ignored addresses" field.  Am I overlooking something in the couchpotato UI?  Or is there some other way to make couchpotato work properly.

 

Thanks

Link to post
On 3/10/2021 at 6:08 PM, UNRAID5 said:

I am not having any luck getting my *arr's to connect to SABnzb. All of my dockers have their own IP, nothing shares IP with unraid. All of the *arr's go through the qbittorrent docker with vpn and privoxy. I can hit all webui's no problem and all openvpn's are connected successfully. Indexers all work and torrents work with all the *arr's. The only thing that isn't working is the *arr's can't see the SABnzb Download Client (they did before updates). Any ideas beyond what is in the FAQ? I have tried every combination that I can think of that is listed in the FAQ and not having any success. Thanks!

 

I can ping each docker from each docker, no problem. I have also tried unchecking Use proxy in the *arr's and they still won't test successfully to SABnzb as a Download Client. That makes me think the issue lies with the SABnzb docker, but I can't seem to find the resolution. Any ideas?

Link to post
On 3/4/2021 at 9:11 PM, Rav20 said:

so when i have a custom IP in BR0 with VPN enabled i cannot access the GUI. if i disable the VPN, i am able to access the GUI. if i use bridge mode i can access the gui but i now have a need to change it to a unique IP address. i've also tried the below commands but it made no change. any advice? whatcha need from me?

 

 

echo "# force iptable mangle module to load (required for *vpn dockers)" >> /boot/config/go echo "/sbin/modprobe iptable_mangle" >> /boot/config/go  and reboot

bueller ?

Link to post

 

On 3/15/2021 at 5:49 PM, UNRAID5 said:

 

I can ping each docker from each docker, no problem. I have also tried unchecking Use proxy in the *arr's and they still won't test successfully to SABnzb as a Download Client. That makes me think the issue lies with the SABnzb docker, but I can't seem to find the resolution. Any ideas?

 

I am fairly confident that iptables is dropping my traffic. I rolled a Firefox docker, to rule out the *arr's entirely, and put it in the same vlan/br interface as SABnzb so it is layer 2 adjacent with nothing in the way (including not sharing the unraid IP, rather I assigned it its own IP). When I try to hit the SABnzb web ui on http://[IP]:[PORT:8080]/ the page times out and doesn't load. Same goes for https on 8090. I tested other internal web UI's to make sure connectivity was good and it is. So I hopped on the SABnzb console and looked at IP the tables hit counts and sure enough I see the drop counter increment when I attempt to hit SABnzb from the Firefox docker.

 

sh-5.1# iptables -L -v -n --line-numbers
Chain INPUT (policy DROP 12 packets, 828 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      125  4455 ACCEPT     all  --  *      *       10.*.*.0/24       10.*.*.0/24      
2       60 19355 ACCEPT     all  --  eth0   *       185.*.*.*        0.0.0.0/0           
3        0     0 ACCEPT     all  --  eth0   *       185.*.*.*        0.0.0.0/0           
4        0     0 ACCEPT     all  --  eth0   *       185.*.*.*        0.0.0.0/0           
5        0     0 ACCEPT     all  --  eth0   *       185.*.*.*        0.0.0.0/0           
6        0     0 ACCEPT     all  --  eth0   *       185.*.*.*        0.0.0.0/0           
7       72  8910 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080
8        0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:8080
9       66  9205 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8090
10       0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:8090
11       0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
12      26  1360 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
13      31  9053 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 0 packets, 0 bytes)

 

It doesn't make sense to me why. My traffic should match rule 1. Worst case scenario it should match rules 7 or 9, respectively. What's interesting is I CAN hit the SABnzb webui from my workstation which is on a different VLAN and IP space. I successfully match rules 7 and 9 from my workstation, which does indeed make sense.

 

Also to note, when I add 8080 and/or 8090 to the ADDITIONAL_PORTS (which states this variable is depreciated in supervisord.log), VPN_INPUT_PORTS or VPN_OUTPUT_PORTS environmental variables, it just repeats rules 7-10 again for both INPUT and OUPUT chains. So these appear to have the same effect as Container Port: 8080 and Container Port: 8090.

 

Not sure how to do a packet capture at this point, so I can see what SABnzb is seeing to try and understand why it's dropping traffic on the same network that should be allowed.

The saga continues...

Link to post

Hi @binhex, just finished updating my sabnzbdvpn, radarr, sonarr, nzbhydra2 setup to work with the latest changes and so far everything seems to be working well!


The only issue I’m still having is that I can no longer reach radarr (port 8989), sonarr (7878), nzbhydra2 (5076) outside my network using my reverse proxy. I used @SpaceInvaderOne tutorial to setup a reverse proxy using Swag and creating a proxynet and after the vpn updates I get a “502 bad gateway” error when trying to access those containers.

 

I tried Q27 in the docs and added each of the ports above to VPN_OUTPUT_PORTS but no luck so far.

54798124_vpninputoutputports.thumb.png.59357c74388f90c906343ee4ef7e8b5e.png

 

Any guidance on how to get to get this working again 🙏

 

Thx

Edited by unRaide
Link to post

Ive set everything up as suggested in the faq, added 8080 to vpn outputs, the *arrs to vpn inputs and tried multiple combinations to test. I can access the UIs no problem and they connect through the vpn ip no problem, But the *arrs just cant communicate with sab and keep timing out. I cant work out why. Ive tried with priv enabled and disabled from the sab config, ive tried with proxy ticked and unticked in the settings of the *arr UIs. No difference. Very stumped here.

 

Edit:

Realised that the default lan network needed changing in the sabnzbvpn config :) all working now

Edited by DioxideC
Link to post
On 2/27/2021 at 1:52 AM, SubRetro said:

So I was able to resolve my issue after a bit of testing.

 

1. I tried the ignore proxy option work around. Didn't work.

2. I tried removing the docker and its imagine and pull back down comparing the config I had. Didn't work.

3. I tried updating ovpn conf file and didnt' work.

 

What I did find that worked was I shut off the docker, removed the ovpn conf file and started the docker up so I can clearly get the expected log message - 

"[crit] No OpenVPN config file located in /config/openvpn/ (ovpn extension), please download from your VPN provider and then restart this container, exiting... "

 

Then based upon the following error message I was getting.

 

2021-02-27 02:05:55,578 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2021-02-27 02:05:55,583 DEBG 'start-script' stdout output:
Options error: Maximum number of 'remote' options (64) exceeded

Use --help for more information.

 

I noticed in my ovpn conf file that there was several entries such as.

*****EXAMPLE******

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com UDP 1234

remote.vpnpiatunnel.com TCP 1111

 

So I removed the duplicate entries for the TCP line items and kept the UDP. Ultimately resulting in this.

 

remote.vpnpiatunnel.com TCP 1111

remote.vpnpiatunnel.com UDP 1234

 

I saved and copied the file over to the proper directory for the docker and started it back up. Now I get expected behavior in the logs and get the end results once the VPN communication gets established. 

 

 SABnzbd process is listening on port 8080

 

Now I am able to get into the WebUI and my reinstalled docker already had all of its config settings in tack as well. I ran verification tests to my nzb providers and made sure my other dockers such as sonarr/raddar were able to verify test connectivity to sabnzbd and to go through the download request process.

 

As of result of all this I have no idea why my conf file had multiple entries. If it was there before and whatever change/requirement was made in this docker update that occurred must of tightened up some requirements and saw that this was an issue in the conf file. Not a deal breaker but when you start to understand the order of behavior with this docker and your setup it certainly helps to walk through the process to better troubleshoot.

 

Thanks for taking the time to read this and hope this might help someone down the line. Thanks.

 

 

 

This solved my issue. Thank you!

Link to post

Hi, 

 

Long time Sabnzbdvpn user with PIA Wireguard. Just logged in down and noticed the below error in the logs and the GUI won't load;

 

2021-04-01 03:23:32,210 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://89.238.137.36/authv3/generateToken'
[info] Retrying in 10 secs...

2021-04-01 03:23:42,233 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

 

Nothing has changed and it was happily downloading when I last checked around six hours ago. I can't find any mention on PIA's site of maintenance issues. 

Link to post
5 hours ago, LoneTraveler said:

Hi, 

 

Long time Sabnzbdvpn user with PIA Wireguard. Just logged in down and noticed the below error in the logs and the GUI won't load;

 


2021-04-01 03:23:32,210 DEBG 'start-script' stdout output:
[warn] Unable to successfully download PIA json to generate token from URL 'https://89.238.137.36/authv3/generateToken'
[info] Retrying in 10 secs...

2021-04-01 03:23:42,233 DEBG 'start-script' stderr output:
parse error: Invalid numeric literal at line 4, column 0

 

Nothing has changed and it was happily downloading when I last checked around six hours ago. I can't find any mention on PIA's site of maintenance issues. 

Switch endpoint, it's just likely a pia outage for whatever endpoint you are attempting to connect to

Link to post
2 hours ago, binhex said:

Switch endpoint, it's just likely a pia outage for whatever endpoint you are attempting to connect to

Thanks for your help. 

 

After changing the endpoint from UK-Manchester to UK-London, the error unfortunately persisted. A quick delete of the wg0.conf file and allowing Sabnzbdvpn to regenerate it has corrected the problem though. 

 

Many thanks. 

Link to post

morning all.

 

is there any definitive way of working out exactly what tunnel the sab information is going through when downloading?

 

So basically I have SabVPN set-up using PIA and wireguard which up until today would give me around 55-60 meg download speeds of my total 1gb connection which is about the max PIA would give me.

 

Sab updated this morning and after that update I am now getting almost max throughput on my connection which is unusual for PIA so now im doubting that I am connected to PIA at all although the docker log shows no errors at all.

 

Clicking on the spanner icon in SAB always seems to be hit or miss at to whether it shows the public IP4 address (seems to show the first time SAB is restarted then very rarely shows anything other than connection failed even though it downloads fine)

 

I thought there was a command you could run in terminal that showed the public ip of a docker but cant seem to find the command.

Link to post

I had a little time to troubleshoot again. This time I used a bigger hammer and disabled iptables all together. Sure enough, the *arrs can now talk to sabnzb now. So at this point I know it's the sab docker and I know it's the iptables rules at fault, but I don't know how to fix it... I suppose I may have to now experiment with adding iptables rules until I find the right one to add, but that doesn't sound very permanent as a restart or update of the docker will undo my changes.

Link to post
I had a little time to troubleshoot again. This time I used a bigger hammer and disabled iptables all together. Sure enough, the *arrs can now talk to sabnzb now. So at this point I know it's the sab docker and I know it's the iptables rules at fault, but I don't know how to fix it... I suppose I may have to now experiment with adding iptables rules until I find the right one to add, but that doesn't sound very permanent as a restart or update of the docker will undo my changes.
Take a look at the recommended post at the top of the screen, this should help you.

Sent from my CLT-L09 using Tapatalk

Link to post
10 hours ago, binhex said:

Take a look at the recommended post at the top of the screen, this should help you.

Sent from my CLT-L09 using Tapatalk
 

 

I have tried them all multiple times, but nothing seems to be working for me. 🤷‍♂️

Link to post
7 minutes ago, UNRAID5 said:

 

I have tried them all multiple times, but nothing seems to be working for me. 🤷‍♂️

ok so can you detail what is routed through what, is this post still how it is setup?:-

 

Quote

I am not having any luck getting my *arr's to connect to SABnzb. All of my dockers have their own IP, nothing shares IP with unraid. All of the *arr's go through the qbittorrent docker with vpn and privoxy. I can hit all webui's no problem and all openvpn's are connected successfully. Indexers all work and torrents work with all the *arr's. The only thing that isn't working is the *arr's can't see the SABnzb Download Client (they did before updates). Any ideas beyond what is in the FAQ? I have tried every combination that I can think of that is listed in the FAQ and not having any success. Thanks!

 

Link to post

Yes, that is still the same. To reiterate: All dockers have their own unique IP's on the same subnet (br0.x). All *arrs are using the proxy configuration through binhex/arch-qbittorrentvpn using privoxy. Then separately I also have binhex/arch-sabnzbdvpn using openvpn only and no privoxy. Everything works minus the *arrs talking to binhex/arch-sabnzbdvpn as a download client using the API key over port 8080.

So far no test rules in iptables are working for me successfully, still thinking of more to possibly try.

 

iptables -I INPUT 1 -s 10.x.x.0/24 -j ACCEPT

iptables -I OUTPUT 1 -d 10.x.x.0/24 -j ACCEPT

iptables -I INPUT 1 -p tcp -m tcp --dport 8080 -j ACCEPT

iptables -I OUTPUT 1 -p tcp -m tcp --sport 8080 -j ACCEPT

iptables -I INPUT 1 -i eth0 -j ACCEPT

What I have noticed so far is the last rule above renders 0 DROPS on the INPUT chain. Which at least makes some sense (I like it when things make sense).

Link to post

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.