Timeouts to NZB Hydra via Public IP and haproy

Help & Support
#1

Sonarr Version: 2.0.0.4326
Mono Version: 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16 13:19:08 UTC 2016)
OS: Ubuntu Server 16.04
Sorry this is so long sometimes I ramble on, but I am just trying to explain everything fully.
All apps are ran in Docker Containers from linuxserver.io where available.
I use haproxy for ssl termination and proxying. No ports are open for any services, all are only locally available on the docker network and made publicly available through haproxy.
I am not a fan of path proxying so all services are available with this style:
sonarr.myurl.com
couchpotato.myurl.com
hydra.myurl.com

Current Containers: Sabnzbd, Sonarr, NZB Hydra, haproxy, couchpotato and others that dont apply to this.
All containers are on a private network that allows them connection to each other via container name or a local IP.
I have just added NZB Hydra, I used to have all indexers setup in each app Sonarr,couch,etc. I have nzbhydra setup and when I go directly to its site I can search and send nzb to sab no problem.
I also have couchpotato setup to use it and it is working without issue, all couchpotato searches and grab appear in the hydra history.
The problem in sonarr is a timeout error whenever trying to add hydra as an indexer.
If I add hydra using the local docker network it works no problem however this requires a few settings in hydra that seems to break it from being available to another server hosted elsewhere that requires public access. I can also open hydra’s port and then enter the public IP and port thus bypassing haproxy and it also works. So this led me to thinking the issue was an haproxy setting, however after setting up couchpotato to use hydra through haproxy and it working leads me back to sonarr.

Sonarr log: http://pastebin.com/rDhhjVRf

NZB Hydra log: doesnt show any incoming connection attempt at all.

The sonarr log shows a timeout error, if I take the URL listed and paste it into chrome and put in the actual API it loads the xml result within 8 sec or less. When I do this the search is listed in NZB Hydra’s logs. I can then take a url from the results and try loading that in chrome and it downloads the nzb just fine.
It all seems to be something causing this timeout error.

URL listed in sonarrr: (changed slightly for privacy): https://hydra.myurl.com

Has anyone else ran into this problem or have any ideas for me to try.
Thanks

#2

Sounds like the proxy isn’t passing the request through then and since Sonarr sees a timeout it’s not closing it immediately either.

Does it work with http instead of https?
Is curl 4 installed? (Sonarr will fallback to that if it can’t make a secure connection with mono’s older SSL support)

#3

That is what I was thinking too, I spent many hours trying to get my HAProxy to log all connection requests/responses etc, but i have been unable to get it to work.
It works just fine though with couch and loading the api urls in chrome. So not sure if it is how sonarr requests it, that haproxy doesnt like and doesnt pass on the connection or what.
I am going to try setting it up to use http and not https and see if I can get that working and go from there. I will have to check on curl 4, since it is ran in a docker image, I doubt there are many extras available.

#4

Sonarr connects just fine through haproxy, if I disable ssl in haproxy.
I have also verified that the sonarr docker container has curl installed and curl returns the xml file using http or https.

I will keep digging
Thanks

#5

You might need libcurl4-openssl-dev installed (if the issue is Sonarr using curl as a fallback), ((trace logs)) during startup will log whether libcurl is available for Sonarr to use or not.

#6

It does appear to be related to Mono and it’s ssl ability.
The docker container did not have libcurl4-openssl-dev installed, so I was able to install it, however that did not fix the problem, maybe I needed to do something else. I did turn on trace logging and restarted sonarr, then search the trace log for curl and the only thing that appeared was: Debug|FallbackHttpDispatcher|https request failed in tls error for torrentapi.org, trying curl fallback.
Nothing where the hydra connection was trying curl.

I did more testing with Haproxy after reading online that mono only uses TLS 1.0 I checked my haproxy config and I had in the SSL options no-tlsv10
So it was not allowing those types of SSL connections I commented it out and reloaded the config and it started connecting.
So the main reason for this not working is Mono supports old (less secure I think) methods of SSL. Because I had my haproxy config restricting certain SSL types it was blocking the connection.

So it appears my options for making this work is to allow SSL TLS v1.0.
I am going to check if this can be applied to the specific hydra backend to allow TLSv1 or if it does have to apply to all of my connections.

Not sure if Mono is working on improving their SSL or if this is what it will always be.

Thanks again for helping lead me to figuring out a workaround.

#7

They are, it finally came out in mono 4.6, but we’ve seen other issues with 4.6 and haven’t looked into what it will take to allow support for TLS 1.1 and 1.2

If Sonarr fails to fallback to curl it will log: Curl not available, using default WebClient. as a Trace-level log message.

#8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.