Reverse Proxy Not Working

[Smithoo4]

I am trying to set up nginx as a reverse proxy with let’s encrypt so I can remotely access Medusa/Sickrage. When I try to access Medusa/Sickrage through the revers proxy Chrome will not load the page given a message "This page is trying to load scripts from unauthenticated sources". If I tell Chrome to load the unsafe script I get a message “Unable to connect to Medusa!” and them a blank page.

I can still access Medusa/Sickrage locally by its IP with no issue. I have also gotten the reverse proxy to work for Plex, CouchPotato, Transmission and Ubooquity with little to no issue.

In terms of settings up the reverse proxy I have basically followed the guides below:

http://www.htpcguides.com/secure-nginx-reverse-proxy-with-lets-encrypt-on-ubuntu-16-04-lts/

http://www.htpcguides.com/configure-sickrage-reverse-proxy-nginx/

The big differences is I currently have nginx running on different box for testing and am using static IP instead of 127.0.0.1 in the config and I have not set user name and password for Medusa/Sickrage. I don't think that should make a diffrences but please correct me if I am wrong.

A copy of my Medusa/Sickrage config.ini can be found here:

http://pastebin.com/fbehWp0N

Medusa Info:
Branch: master Commit: 677b47ac1f6a75abc71c4472f3fb9c4eecb6413f Version: v0.1.9 Database: 44.3 Python Version: 2.7.12 (default, Nov 7 2016, 11:55:55) [GCC 6.2.1 20160830] SSL Version: OpenSSL 1.0.2j 26 Sep 2016 OS: Linux-4.8.13-1-ARCH-x86_64-with-glibc2.2.5 Locale: en_CA.UTF-8

I am not sure if this is an Medusa/Sickrage or a issue with how I have setup nginx, but any help would be appreciated. Please let me know if there is any other info need.

Thank you for your help and this great project.

[OmgImAlexis]

You may want to reset your API key since you just posted it here.

With the errors coming up does it state which scripts are being loaded from "unauthenticated sources"?

[Smithoo4]

Good point about the API key, I just rest it. I did not even think about that.

The link below is an output from chrome when it give the message "This page is trying to load scripts from unauthenticated sources".

http://pastebin.com/mJTqKE2j

This link is when I tell chrome to load the unsafe script:

http://pastebin.com/X54BdjCP

I have changed my domain name in these logs.

Hope this is helpful and thank you for your help.

[Xenocell12]

I can confirm this as well. For me, it has been a long lasting issue. This is the only fork I've had issues with reverse proxy. However I am using IIS URL rewrite. The reason you are also getting some items are not safe is because they are not being forwarded through reverse proxy and trying to load it as if you were through a local lan. I've been puzzled since and just kept it off the web.

[OmgImAlexis]

Can I have a look at your reverse proxy settings? It sounds like the headers aren't being set.

These should be set for Medusa to handle reverse proxying. You need at least the last two for it to rewrite to https correctly.

Host {host}
X-Real-IP {remote}
X-Forwarded-For {remote}
X-Forwarded-Proto {scheme}

If you're using Caddy instead of Nginx or IIS then this works perfectly.

my_domain.com {
    tls self_signed # Remove the self_signed and it'll issue a Let's Encrypt cert
    proxy / localhost:8081 {
    }
    cors
}

[OmgImAlexis]

For Nginx this is similar to what you should have.

server {

    listen 443;
    server_name my_domain.com;

    ssl_certificate           /etc/nginx/cert.crt;
    ssl_certificate_key       /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    location / {
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      proxy_pass          http://localhost:8081;
      proxy_read_timeout  90;

      proxy_redirect      http://localhost:8080 https://my_domain.com;
    }
  }

[OmgImAlexis]

For IIS make sure to have these setup.

<serverVariables>
    <set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
    <set name="HTTP_X_FORWARDED_SCHEMA" value="https" />
    <set name="HTTP_X_FORWARDED_PROTO" value="https" />
</serverVariables>

[Smithoo4]

I have gotten my nginx reverse proxy to work by adding the “proxy_set_header X-Forwarded-Proto $scheme;” line to my settings; i.e.:

# SickRage
 location /sickrage {
   proxy_pass http://127.0.0.1:8081;
   proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
 }

Otherwise my settings are the same as what is list in htpcguide; link below:

http://www.htpcguides.com/secure-nginx-reverse-proxy-with-lets-encrypt-on-ubuntu-16-04-lts/

The

      proxy_read_timeout  90;
      proxy_redirect      http://localhost:8080 https://my_domain.com;

lines seem to give errors. Although as type this I think the may be because of the port number used. Should it be 8081 not 8080?

Thank you for your help

[OmgImAlexis]

Ah yes it should be 8081, I took that snippet from my own nginx config so I had to remove a lot of other code and forgot to change that back.

If you need any help just reopen this. 😃

[CHBMB]

OK, I admit defeat with this one. Trying to get it working with our Letsencrypt container with no success. Could someone please post a config that works? I've tried multiple different combinations of stuff here with no success. This was working up until recently.

The config below works fine without the auth. I have no auth setup within Medusa, only the changes detailed below.

# Medusa
# 
#
# WITH THE CONTAINER STOPPED
# Edit /config/config.ini and change line 22 (by default)
# from web_root = ""
# to web_root = "/medusa" and change line 43 (by default)
# from handle_reverse_proxy = 0
# to handle_reverse_proxy = 1

location /medusa {
    proxy_pass http://10.1.1.3:8081/medusa;
    include /config/nginx/proxy.conf;
    auth_basic "Restricted";
    auth_basic_user_file /config/nginx/.htpasswd;       
}

proxy.conf

client_max_body_size 10m;
client_body_buffer_size 128k;

#Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Advanced Proxy Config
send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;

# Basic Proxy Config
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 32 4k;

@OmgImAlexis

[OmgImAlexis]

@CHBMB I'll look at this today. It should be pretty simple as I have this setup with auth on my docker container right now.

[CHBMB]

@OmgImAlexis Thanks man, appreciated.

[Thraxis]

@OmgImAlexis @CHBMB

I tested this on my unraid setup today as I was setting up the letsencrypt docker. Tracking things down it appears that there's an issue with the api v2 route when using a reverse proxy:

https://<site>.duckdns.org/medusa/api/v2/config

returns:

{"error": "Invalid user/pass."}

If you set a username and password in your config then the reverse proxy will work, but will require you to modify any third party api calls to include username and password (sickrage connect, nzbToMedia, etc)

[OmgImAlexis]

No 3rd party scripts use api v2 yet so this shouldn't effect anything and the site itself passes it's auth through an api key.

It's 100% normal to see that error if you just visit the url in your browser.

[CHBMB]

@OmgImAlexis Any luck with this?

[OmgImAlexis]

I'm still not sure what the actual issue is as it's working 100% on my end with a very similar setup.

I'll try to get to the bottom of this today.

[CHBMB]

@OmgImAlexis Any chance you could post your config and I'll try it this end? What setup are you using exactly?

[OmgImAlexis]

The same one as above. I've even tried the nginx proxy I use for my UNRAID setup and don't seem to be having any issues.

[Thraxis]

@OmgImAlexis I don't think Medusa behaves well when run through nginx with a web_root = "/medusa", which is what CHBMB is trying to do.

You're running your reverse proxy as medusa.<subdomain>.duckdns.org where CHBMB was trying to setup <subdomain>.duckdns.org/medusa

[OmgImAlexis]

@Thraxis no... I'm using /medusa and medusa.domain.com both work perfectly for me.

[OmgImAlexis]

@CHBMB can you post your entire nginx file for me? I want to try with exactly what you're using.

[CHBMB]

@OmgImAlexis Sure thing

server {
       listen         80;
       server_name    server.com;
       return         301 https://$server_name$request_uri;
}

server {

    listen 443 ssl default_server;
    server_name server.com;

    ###Set root directory
    root /config/www;
    index index.html index.htm index.php /h5ai/_h5ai/public/index.php;

    ###Turn off client checking of client request body size
    client_max_body_size 0;

    ###SSL Certificates
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;

    ###Diffie–Hellman key exchange ###
    ssl_dhparam /config/nginx/dhparams.pem;

    ###Extra Settings###
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

        ### Add HTTP Strict Transport Security ###
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header Front-End-Https on;

    ###SSL Ciphers
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        # With php5-cgi alone:
        fastcgi_pass 127.0.0.1:9000;
        # With php5-fpm:
        #fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include /etc/nginx/fastcgi_params;

    }

        location /medusa {
        proxy_pass http://192.168.0.100:8081;
        auth_basic "Restricted";
            auth_basic_user_file /config/nginx/.htpasswd;
        include /config/nginx/proxy.conf;
    }
}

[CHBMB]

I own the domain name, rather than it being a duckdns address FWIW.

[CHBMB]

@OmgImAlexis

Any luck?

[OmgImAlexis]

No, that's why I hadn't replied. Everything I try with your config but with my own domain works perfectly.

Can you provide the exact error, etc. and maybe a screenshot? There may be possibly something different between our setups.

[CHBMB]

Hmmm, that's interesting. You using our docker container for Medusa? and our letsencrypt docker container?

[OmgImAlexis]

Yep and even with a standard nginx container I'm not having any issues at all.

[medariox]

Is there a working config yet? I can confirm this issue. Can also give you access to look into this @OmgImAlexis, just let me know.

[OmgImAlexis]

@medariox I've tried nginx and caddy both in and out of docker containers, on OSX and linux with my config and ones above with no issues any of the time so I'm not sure where people's issues are coming into it. I'd have to actually have access to someone's setup where they have an issue to try and diagnose it.

If someone can actually give me an error code or post some screenshots of the issue I may be able to work this out a little easier.

[ghost]

I have the same issue. Removing

auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;

works. Without auth everything is fine, with auth i get the "Cant connect to Medusa!" error. Everything else behind the reverse proxy works flawlessly.

[OmgImAlexis]

@ratoaq2 since I think I know the issue here should I fix this in the API or wait for your PR to be merged as I'll need to change the way the prepare section is handled.

[ratoaq2]

You can fix and I'll rebase my pr

[CHBMB]

Thanks @OmgImAlexis and @ratoaq2, I'd kind of forgotten about this due to being rather busy.....

[ghost]

Is there any news regarding this topic?

[OmgImAlexis]

Yes, fixing this in the next few days. Been really busy with real life stuff.

@ratoaq2 if you get to this before me we basically need to allow any of the auths to pass as we get the basic auth from the proxy which is making medusa think the auth is invalid even though the api key is also passed to medusa.

Since we check auth before the api key it's hitting a race condition.

[medariox]

I can confirm that the issue is fixed with: https://github.com/pymedusa/Medusa/pull/2413

[medariox]

@CHBMB @hagabla This should be fixed now, sorry for the wait.

[CHBMB]

@medariox Thanks very much, no need to apologise, we know what it's like with these things. Appreciate you guys looking into it and providing the fix. :+1:

[ghost]

Everything is fine now, thank you very much!