binhex

Incorrect, it uses the name servers defined for NAME_SERVERS, it does not use whatever your host is using. To resolve the vpn endpoint (if its a name) and to do all name resolution for the application e.g. resolving peers/seeds from name to ip (if talking about a torrent client). Before AND after the tunnel is connected, but once connected all future name server lookup is restricted to vpn tunnel only, if the tunnel goes down then name server lookup for the endpoint is done via cached lookups in the form of hosts file. Not all vpn providers provide name servers to use, and even if they do not all vpn name servers are publicly accessible, so name resolution for the vpn endpoint (prior to being connected to the vpn) would be blocked resulting in the inability to establish a connection. Firstly lets correctly define what name server ip leakage really is, this is leaking your ISP assigned ip via name server lookup, this cannot happen with this image, as mentioned above name server lookup is restricted to vpn tunnel only once connected, in the above scenario firefox will be using a public name server (1.1.1.1) but the requests will be coming from your vpn provider ip address and will not be from your isp assigned ip address, thus no leak. For anybody else reading this, please keep in mind that nickydd9 is using a firefox browser in a container, and thus all traffic is sent down the vpn tunnel, if you are using a browser via privoxy (proxy) then this is a different scenario and name server leakage will occur.

from your log file:- [info] ProtonVPN username 'vpn username' does not contain the suffix '+pmp' and therefore is not enabled for port forwarding, skipping port forward assignment... follow Q31:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

from your log:- 2024-01-17 22:41:00 [UNDEF] Inactivity timeout (--ping-restart), restarting See Q17:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Sorry looks like i was wrong, the upstream is targeting nightly, so hopefully you should have your fix, i will at some point switch this to releases only once Readarr gets a little more stable.

Looks like the endpoint you are specifying (via ip) is not operational any more, download a new wg0.conf from protonvpn for a different endpoint, from your log:- readnatpmpresponseorretry() failed : the gateway does not support nat-pmp

firstly you cannot ping an ip address specifying the port. And as you highlighted, the LAN_NETWORK is incorrectly configured, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

you need to go to the support thread for that image, i'm sorry i cannot support other images.

Possibly, yes, Realtek NIC's are notorious for having bad linux drivers leading to issues, i think there are drivers available via unraid 'plugins' but i have no idea if they will fix your TLS issue or not. NIC = Network Interface Card.

whichever nic is connected.

i guess you could try the nzbget-ng image, but i have no idea if the unpack issue exists or not. As for the TLS issues it maybe driver related, are you running Realtek NIC's by any chance?

you tell me :-), i only have experience of running nzbget on unraid. i hate to say this but you may have better success with the Linuxserver nzbget image, i THINK it has less occurances of the unpack isssue, NO idea why it doesnt suffer from it so much *shrug* the workaround is built into the image, are you saying you are still seeing TLS related issues then, if so detail what you see.

releases, as can be seen here:- https://github.com/Readarr/Readarr/releases when a new release is created then a build will be automatically triggered and if successful it will be pushed to multiple registries.

misconfigured LAN_NETWORK, from your log:- 2024-01-15 23:35:13.714631 [info] LAN_NETWORK defined as '192.168.0.1/24' See Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Are the other containers (sonarr etc) set with ip's in the defined LAN_NETWORK? as in 192.168.0.xxx? The other question is have you changed the ip you are using in the other containers (sonarr etc) to use <ip of your unraid server>:8118? The last thing to also check is that you are bypassing proxy for local addresses for the other containers (sonarr etc), screenshot:- this is from my server, change the ip to 192.168.0.* for your setup.

Unpack, yes, TLS is a nzbget issue and has a workaround in place.

See my previous post Sent from my 22021211RG using Tapatalk

nope, it has been this way for literally years!, i can only assume something in unraid has changed and this has resulted in an influx of users with this 'issue', have you recently upgraded unraid or switched from macvlan to ipvlan perhaps?.

This is your issue, you are specifying a static ip (192.168.0.111) for the container that is in the LAN range (192.168.0.0/24), this breaks the container, switch the docker container back to bridge.

If nothing has changed its 99% probability its VPN provider related, do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

probably corrupt database discussed a few posts back, there are no known issues with the image. Sent from my 22021211RG using Tapatalk

Q1:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

OK fair enough, i just assumed you were talking about usenet as we are in the support thread for SABnzbdVPN 🙂

So you got a DMCA notice from a usenet download?, that is highly unlikely as most if not all usenet providers use TLS encryption and therefore any downloads will not be visible to your ISP either with the VPN turned or not. The VPN is purely there to prevent your usenet provider from being able to identify your IP and therefore potentially (highly unlikely) inform your ISP or copyrights holders of your activities.

Because if the vpn fails to come up the application is not started and thus you cannot access the web ui, its a safety feature to prevent ip leakage. This is your issue, from your log:- [UNDEF] Inactivity timeout (--ping-restart), restarting see Q17:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

if its happened all of a sudden its nearly always vpn provider related, do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md