[Support] binhex - PrivoxyVPN


binhex

Recommended Posts

5 minutes ago, binhex said:

not required for jackett, this is used when you want to talk from a container running inside the vpn network to another container running on the lan, this is not the case for jackett.

Not to create a tangent, I would have to do this for Sonarr to talk to Jackett then?

 

restarted and went to 192.168.1.159:6000  no web interface.

ServerConfig.json

Link to comment
9 minutes ago, DaSlinky said:

Not to create a tangent, I would have to do this for Sonarr to talk to Jackett then?

no, because sonarr talks to jackett, not the other way around and therefore its inbound traffic to the vpn network, not outbound.

 

ok can you drop to the console of the vpn container and run the command:-

 

iptables -S

and then paste the output here

Link to comment
3 minutes ago, binhex said:

iptables -S

sh-5.1# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s 138.199.27.241/32 -i eth0 -j ACCEPT
-A INPUT -s 138.199.27.221/32 -i eth0 -j ACCEPT
-A INPUT -s 138.199.27.231/32 -i eth0 -j ACCEPT
-A INPUT -s 138.199.27.232/32 -i eth0 -j ACCEPT
-A INPUT -s 138.199.27.212/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9117 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 9117 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 138.199.27.241/32 -o eth0 -j ACCEPT
-A OUTPUT -d 138.199.27.221/32 -o eth0 -j ACCEPT
-A OUTPUT -d 138.199.27.231/32 -o eth0 -j ACCEPT
-A OUTPUT -d 138.199.27.232/32 -o eth0 -j ACCEPT
-A OUTPUT -d 138.199.27.212/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9117 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 9117 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.1.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
sh-5.1# 

Link to comment
36 minutes ago, DaSlinky said:

sh-5.1# iptables -S

looks fine, can you check your browser, ensure it does NOT have proxy set, im assuming you are trying to connect to the jackett web ui from a machine with an ip in the 192.168.1.x range right?

Link to comment
6 hours ago, binhex said:

with an ip in the 192.168.1.x range right?

So... out of freaking curiosity I did a route print and enclosed it.  It did not work but I'm VPN'd into my home network (at this time) being assigned a 172.x.x.x address.

192.168.128 is my address scheme at the office.

172.27.224.9 is my VPN address into my home network, that is set to be the 192.168.1.x

 

Just got home have 192.168.1.155 as a local address... still no UI when i goto 192.168.1.159:6000

😅

 

UPDATE!

Not the best of news, but at this stage Sonarr / Deluge / Jackett are all talking to each other.  The big rip is I can't see the Jackett webUI.  

 

Of all things I guess that's the LEAST of my worries, I'd rather not have to monkey with the port/network parameters to do a full reconfigure.. but once that's done its done?

 

I hope you're still game to get the webUI working, I am 😁

 

image.png.88a33cb54e81e3a6100ab7d4f0c4c988.png

 

Edited by DaSlinky
geography update
Link to comment
11 hours ago, DaSlinky said:

I hope you're still game to get the webUI working, I am 😁

i think im getting to the end of my list of things to try, there is something external going on here, check firewall, check vlan's, try another browser, try another pc/device, ensure you are doing all of the previous on your lan NOT over a vpn to your home network, as this just adds complexity.

Link to comment
i think im getting to the end of my list of things to try, there is something external going on here, check firewall, check vlan's, try another browser, try another pc/device, ensure you are doing all of the previous on your lan NOT over a vpn to your home network, as this just adds complexity.

I tried my HP laptop, iPad, MacBook(intel) and a win10 VM from unraid machine itself(daily driver) on the 192.xxx network. Same thing.

Tempted to send you vpn credentials so you can work on it directly


Sent from my iPhone using Tapatalk
Link to comment

Is there a way to whitelist a webpage e.g. *.example.com to bypass the proxy settings? This mainly an IOS related problem as on my regular computer I can set certain websites to bypass the proxy. This feature is not available on IOS.

Link to comment

HI.

 

I have been using this container for while to use a VPN for ZNC and for NZBGET. Both of the containers have the custom network type in the template Custom: container:binhex-privoxyvpn. I have added the ports of NZBGET and ZNC containers to the privoxyvpn one,

 

I also use the privoxy part of the container and have configured Sonarr and Radarr to use the proxy on port 8118. I also have the proxy configured in windows using port 8118 for web broswing.

 

Everything has been working great for months. However, I am running into issues now. Not sure if it is due to an update or something on my end.

 

1) I cannot access the nzbget or the znc webui's at all. This is in a browser going through the proxy or one that does not. ZNC seems to be running fine however as I am able to connect and chat etc.

2) radarr and sonarr have lost connectivity with nzbget (radarr and sonarr don't have the privoxyvpn network type, only the proxy port configured),

3) web browsing through the proxy in windows does not work at all.

 

I am stumped as I have been using this with no problems for months and have not changed anything. Any ideas?

 

Thank you for the help. Id be happy to attach any logs etc just not sure which ones are needed.

Link to comment
1 hour ago, xxxliqu1dxxx said:

Did you add 6000 to ADDITIONAL_PORTS as well as adding it the "old way"?

**I was getting restricted port on ios, so i moved it to 8088**

added the additional ports variable, verified the key was proper, have 9117, 8088 

I also have 9117, 8088 as VPN_INPUT_PORTS

VPN_OUTPUT_PORTS is blank/empty

added additional port JACKETT, container port 9117, host port 9117 connection type TCP

Link to comment

Thanks for the extensive documentation, it's really useful.

 

Anyone have experience on what happens if you have a watchtower container that tries to update this container (arch-privoxyvpn's) when a different (e.g. jackett) depends on this one network through e.g. --network=container:arch-privoxyvpn?

 

According to your document the order matters, but does that lead to IP leakage if WT tries to update it; or does it even fix itself after doing it?

 

Looking for best practices; hoping watchtower doesn't need to be nixed since I do have lots of containers it works well with.

Edited by Rinzler
Link to comment
10 hours ago, DaSlinky said:

@theGrok Did you get it to work?  I still can't get to my Jackett on :6000.  

Hi, I don't use jackett but i've added the ADDITIONAL_PORTS variable and I still cannot access my webuis of containers that I route through the VPN if I am using browser that is using the proxy (8118). I can't access anything that has the IP address of the host including the unraid webui. Web browsing works fine. I can access all of the webui from a browser that doesn't use the proxy. I will have to have a fresh look this weekend when I have more time; In clearly doing something wrong

Edited by theGrok
Link to comment
Hi, I don't use jackett but i've added the ADDITIONAL_PORTS variable and I still cannot access my webuis of containers that I route through the VPN if I am using browser that is using the proxy (8118). I can't access anything that has the IP address of the host including the unraid webui. Web browsing works fine. I can access all of the webui from a browser that doesn't use the proxy. I will have to have a fresh look this weekend when I have more time; In clearly doing something wrong
This should be able to be resolved by simply adding an exclusion to your you're proxy settings for your browser such that it excludes LAN IP addresses from being routed via the proxy.

Sent from my CLT-L09 using Tapatalk

Link to comment
3 hours ago, binhex said:

This should be able to be resolved by simply adding an exclusion to your you're proxy settings for your browser such that it excludes LAN IP addresses from being routed via the proxy.

Sent from my CLT-L09 using Tapatalk
 

Hi @binhex. Thank you That seems to have done the job for everything except the Unraid WebUI. Does that have something to do with the fact that I am using https and it has to go out and validate?

Link to comment
2 minutes ago, theGrok said:

Does that have something to do with the fact that I am using https and it has to go out and validate?

i wouldnt of thought so no, can you post a screenshot of your web browsers proxy settings showing the exclusions

Link to comment
7 minutes ago, binhex said:

i wouldnt of thought so no, can you post a screenshot of your web browsers proxy settings showing the exclusions

 

 

At first I only had the hosts local IP 192.168.1.12 I added the long number.unraid.net and now it works. I am not sure if this is correct/good practice as I am no expert in any of this. This screenshot is from windows 10

 

proxy.JPG

Link to comment
1 hour ago, theGrok said:

I added the long number.unraid.net and now it works

you obviously have an option enabled that i dont have, not entirely sure what the *.unraid.net hostname is all about, cloud authentication perhaps i dunno, but im glad you got it working.

Link to comment

Good morning all!  @binhex being new to the community I see your name everywhere, thanks for all of your work and support.

 

With that being said, I need some help if you can, as time permits.  I've been attempting to use this container, along with others of yours, related to VPN and have been getting horrible speeds with Windscribe.  I've tried configs for OpenVPN and Wireguard, different protocol and port combinations, different endpoints ranging from the other side of the planet to some within 2-3 hours drive of me.  No matter what I pick the results are the same, horrible speeds.  To test further I've installed ich777's Firefox container and installed Windscribe's Firefox applet.  Using the same servers I've been able to max out my line speeds without issue.  Just an FYI, for testing speeds from this container, and others, I've installed the speedtest.net cli tools or used their website for testing the speeds to make sure all testing was done from the same place.

My apologies for the possible scrambled thoughts, rough day already.   :P

Any help would be greatly appreciated.

Link to comment

@binhex  I moved all my ports from 6000 to 8088, still didn't work.  There was an update to the container and I pushed it down.  Now everything works!  Seems funny that I still access Jackett on the native 9117 IP vs 8088.  Not even questioning it though!

Link to comment
On 3/3/2021 at 9:16 AM, mbc0 said:

Hi @binhex I posted on the wrong thread the other day, reposting on this, the correct thread as didn't want you to think I was ungrateful!

 

I have managed to get all my containers talking to each other in your container now and can now access all my containers WebUI's and they are all talking to each other.  The answers were there in your guide & Q&A I just needed some help understanding a few things.

 

Just wanted to say a MASSIVE thank you for your work, time and patience, it is HUGELY appreciated!

Hey @mbc0, I think I've had much the same issue as yourself with xteve and the VPN container. I read the last few posts you had with binhex and understood it that both xteve and Plex are both in the VPN network in order to communicate, or should I take it from this that there's another way? Sorry to just piggyback on your hard work, but I'm totally lost on this particular problem.

Edited by Ciaran Madden
Link to comment
2 minutes ago, Ciaran Madden said:

Hey, I think I've had much the same issue as yourself with xteve and the VPN container. I read the last few posts you had with binhex and understood it that both xteve and Plex are both in the VPN network in order to communicate, or should I take it from this that there's another way? Sorry to just piggyback on your hard work, but I'm totally lost on this particular problem.

does xteve talk to plex or does plex talk to xteve? i know there is two way communication but which way is it initialized?

Link to comment

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.