[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

Loosing my mind here. I've read all the documentation but it doesn't seem like http val is working through port 81 (port 80 is blocked by my isp). Am I missing something obvious? 

 

GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Generating a 2048 bit RSA private key
...........................................+++
...............................................................+++
writing new private key to '/config/keys/cert.key'
-----
Subject Attribute /C has no known NID, skipped
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
..............................................................................................................................................................................................+.....................................................................+..................................................................................................................+...........................................................................................................................................................................................................+.............................................................+...............................................................................................................................................................................................................................+...................................+......................................................................................+..................................................................+......................................................................................+...............+.....................................+..........................+......................+.........+...............................................................+..................+.........................................+............................++*++*
DH parameters successfully created - 2048 bits
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d cloud.mydomain.com -d plex.mydomain.com -d sub.mydomain.com
E-mail address entered: [email protected]
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for cloud.mydomain.com
http-01 challenge for plex.mydomain.com
http-01 challenge for sub.mydomain.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sub.mydomain.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://sub.mydomain.com/.well-known/acme-challenge/MEvrkt3fJDynbKusl8MOWChxb2xwXOUIBS2VmP5F0-Y: Timeout, cloud.mydomain.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://cloud.mydomain.com/.well-known/acme-challenge/0A9qgBNPVAiABn6234vnTQurk8uK5fnWsqy-L86wvTI: Timeout

IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: sub.mydomain.com
Type: connection
Detail: Fetching
http://sub.mydomain.com/.well-known/acme-challenge/MEvrkt3fJDynbKusl8MOWChxb2xwXOUIBS2VmP5F0-Y:
Timeout

Domain: cloud.mydomain.com
Type: connection
Detail: Fetching
http://cloud.mydomain.com/.well-known/acme-challenge/0A9qgBNPVAiABn6234vnTQurk8uK5fnWsqy-L86wvTI:
Timeout

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

 

Screen Shot 2018-01-22 at 2.09.59 PM.png

Screen Shot 2018-01-22 at 2.10.22 PM.png

Link to comment
2 minutes ago, neebski said:

it doesn't seem like http val is working through port 81 (port 80 is blocked by my isp). Am I missing something obvious? 

Sort of. You stated the problem very well. If port 80 is blocked, you can't use httpval. Period. End of Sentence.

 

You will have to figure out one of the other methods for getting certificates from LE.

Link to comment
6 minutes ago, jonathanm said:

Sort of. You stated the problem very well. If port 80 is blocked, you can't use httpval. Period. End of Sentence.

 

You will have to figure out one of the other methods for getting certificates from LE.

 

I wrongly assumed by changing the port to 81 on the config that would help. Thanks. Suggestions on alternatives?

Link to comment

What other reasons might there be for validation to time out OTHER than httpval=false or port blocking? I've absolutely positively confirmed that it's attempting to validate on port 80 (httpval) and that my ISP isn't blocking port 80 (I can access the challenge server root from outside my network when it's attempting). But still timeouts! 443 external is also mapped to 444 internal, which is of course what I put in the docker 443 mapping as well...what else could I possibly be missing?

Link to comment
4 minutes ago, drumstyx said:

What other reasons might there be for validation to time out OTHER than httpval=false or port blocking? I've absolutely positively confirmed that it's attempting to validate on port 80 (httpval) and that my ISP isn't blocking port 80 (I can access the challenge server root from outside my network when it's attempting). But still timeouts! 443 external is also mapped to 444 internal, which is of course what I put in the docker 443 mapping as well...what else could I possibly be missing?

 

Link to comment
7 hours ago, Diggewuff said:

Hey,

today I tried to switch my letsencrypt container from Bridge network mode to the new mode in unraid 6.4.0 where I can chose a dedicated IP for the container.

So far so good.

I've chosen a new ip 192.168.1.20 and changed the mapping of the ports 80 and 443 on my router to that new IP.

From then on I wasn't able to reach my domains from WAN anymore. 

trying to access them from LAN is giving me that error:

Furthermore I'm not able to ping any ip dresses on my local network from inside of the container. 

I already disabled every firewall rule on my Router.

 

Does anyone has an idea?

Are you getting this error outside of your network and/or internal?

 

 

Link to comment
On 1/12/2018 at 11:57 PM, matthope said:

In my case, my internet provider block the port 80 so the HTTPVAL fix wont work.

 

Since TLS-SNI challenge is deactivated and I can't use HTTP challenge, I'm obligated to use the DNS-01 challenge. I've found a way to use it with this docker and cloudflare. You will need those 2 scripts ( here ) and you will need to modify the script /etc/cont-init/50-config inside the docker. 


docker exec -it [DOCKERNAME] /bin/bash
vi /etc/cont-init.d/50-config

In the file comment this line :


certbot certonly --non-interactive --renew-by-default --standalone --preferred-challenges $PREFCHAL --rsa-key-size 4096 $EMAILPARAM --agree-tos $URLS

And add this one :


certbot certonly --agree-tos --manual --manual-public-ip-logging-ok --preferred-challenges=dns --manual-auth-hook /app/authenticator.sh --manual-cleanup-hook /app/cleanup.sh --rsa-key-size 4096 $EMAILPARAM --no-eff-email $URLS

 

However, this is a one time fix since any modification to the docker is reverted when restarted. 

 

@aptalca It would be nice if the DNS-01 challenge could be added definitively to this docker.

 

Has anyone else been able to get this to work. Since Cox blocks port 80 I have no other option except the dns verification option but I'm not sure how I can apply this method with my DNS provider.

Link to comment

Hi All

So i am finally back up and running. 

A trap that i also found myself in was my ISP also changing me to a new static IP address. (i suspect maybe due to all the port 80 hits?) Not sure, but it took me forever to figure this out, as my IP has not changed in years. 

 

I installed the nginx docker. 

Copied over my config files from the letsencrypt config folder

Used - docker exec -it letsencrypt /bin/bash/ 

to get into the letsencrypt container so i could use certbot

I then used a certbot command to manually obtain certificates for my domains (similar to what is posted here https://serverfault.com/questions/750902/how-to-use-lets-encrypt-dns-challenge-validation)

 

Note this method does not use the API, you are required to log into your hosting and manually add in TXT records to your DNS zone editor. 

 

Once that was complete, i copied out the 4 files (from the archive folder not the symlinks) and pasted them into my config folder on my cache drive where i could access them. 

 

I then created a letsencrypt folder under my nginx/keys folder (so it looks like /nginx/keys/letsencrypt)

Then i copied the fullchain.pem and privkey.pem files that were created by certbot there. 

 

I then stopped the letsencrypt container, and started the nginx container and it seemed to work / pickup where i had left. 

 

This did involve some trial and error, but that is mainly because i am not very familiar with what i am doing. 

 

In my case, i will need to manually renew the certs and repeat the same procedure in 3 months, but hopefully by then a solution to TLS is found. 

 

Cheers

Brett

Link to comment
1 hour ago, Nem said:

is there a way to put openvpn access server's webgui behind an nginx reverse proxy?

 

Hi Nem, 

 

I've been able to do it by using the stream directive in nginx, which uses SNI to direct the ssl stream to the right service.

Add the following to your LE's nginx.conf

stream
{
    map $ssl_preread_server_name $name
    {
        fred.duckdns.org fred;
        default barney;
    }

    upstream barney
    {
        #openvpn container
        server 192.168.2.37:9443;
    }

    upstream fred
    {
        # upstream nginx virtual hosts such as sonarr, radarr, nzbget, etc.
        server 192.168.2.37:4430;
    }

    server
    {
        listen 443 so_keepalive=on;
        proxy_pass  $name;
        ssl_preread on;
    }
}

 

and then something like this in your LE's site-configs/default

#main server block
server {
       listen 4430 ssl default_server;

       root /config/www;
       index index.html index.htm index.php;

       server_name fred.duckdns.org;

       ssl_certificate /config/keys/letsencrypt/fullchain.pem;
       ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
       ssl_dhparam /config/nginx/dhparams.pem;
       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';
       ssl_prefer_server_ciphers on;

       client_max_body_size 0;

       location / 
       {
          try_files $uri $uri/ /index.html /index.php?$args =404;
       }

location /lidarr 
    {
       include /config/nginx/proxy.conf;
       proxy_pass http://192.168.2.37:8686/lidarr;
    }

    location /nzbget/
    {
       include /config/nginx/proxy.conf;
       proxy_pass http://192.168.2.37:6789;
    }

    location /nzbhydra/
    {
       include /config/nginx/proxy.conf;
       proxy_pass http://192.168.2.37:5075;
    }

    location /radarr
    {
       include /config/nginx/proxy.conf;
       proxy_pass http://192.168.2.37:7878/radarr;
    }

    location /sonarr
    {
       include /config/nginx/proxy.conf;
       proxy_pass http://192.168.2.37:8989/sonarr;
    }
}

 

The first (stream) block basically uses the requested host name to direct the request to either openvpn, or sends traffic on to nginx (same instance) for processing by your virtual host (note sure if virtual host is the right name here)

 

Ports / ip addresses are relevant for my installation - adjust for your own setup

 

Edited by Ding Dong Del
Link to comment
21 hours ago, aptalca said:

Check if there's anything listening on the host

 

Hi @aptalca,

I can't get to that installation until the end of the week - from memory there was a docker-proxy process listening on the host on the ports specified in the container config (e.g. :80) from the screenshot above. 

 

container is in bridge mode at the moment, and was mapping port 80 (host) to 80 (container) so was thinking that docker-proxy process listening on :80 on the host "didn't look wrong".

 

 

Link to comment
11 minutes ago, Ding Dong Del said:

 

Hi Nem, 

 

I've been able to do it by using the stream directive in nginx, which uses SNI to direct the ssl stream to the right service.

Add the following to your LE's nginx.conf

...

The first (stream) block basically uses the requested host name to direct the request to either openvpn, or sends traffic on to nginx (same instance) for processing by your virtual host (note sure if virtual host is the right name here)

 

 

Thanks, I tried it but none of my sites are working now. Most likely due to me not know exactly what needs to be changed. Here's what I changed things to:

 

stream
{
    map $ssl_preread_server_name $name
    {
        example.net/ovpn fred;
        default barney;
    }

    upstream barney
    {
        #openvpn container
        server 192.168.187.10:9453;
    }

    upstream fred
    {
        # upstream nginx virtual hosts such as sonarr, radarr, nzbget, etc.
        server 192.168.187.10:443;
    }

    server
    {
        listen 443 so_keepalive=on;
        proxy_pass  $name;
        ssl_preread on;
    }
}

sites-config/default basically looks the same as yours, only difference is the server is listening on 443

 

My goal is to be able to hit openvpn-as webgui when I go to /ovpn

Link to comment
1 minute ago, Nem said:

 

My goal is to be able to hit openvpn-as webgui when I go to /ovpn

 

My bad - I left out a key piece!

I am using hostnames to get to either openvpn (via a vpn client), or my nginx reverse proxies.

 

so using the example above, I have two duckdns domains set up (fred, and barney) and if I want to get to sonarr e.g. I use:

https://fred.duckdns.org/sonarr

 

when I want to connect to my vpn, I point my vpn client at barney.duckdns.org.

 

I've done it this way on purpose so that both the reverse proxy, and openvpn are listening on 443 externally so that if behind a firewall I can still use my vpn.

that is a slightly different use case than you described.

Link to comment
7 minutes ago, Ding Dong Del said:

 

My bad - I left out a key piece!

I am using hostnames to get to either openvpn (via a vpn client), or my nginx reverse proxies.

 

so using the example above, I have two duckdns domains set up (fred, and barney) and if I want to get to sonarr e.g. I use:

https://fred.duckdns.org/sonarr

 

when I want to connect to my vpn, I point my vpn client at barney.duckdns.org.

 

I've done it this way on purpose so that both the reverse proxy, and openvpn are listening on 443 externally so that if behind a firewall I can still use my vpn.

that is a slightly different use case than you described.

 

I dont mind setting up a subdomain like vpn.site.com, but is there a way to set this up without duckdns?

 

my use case, I think, is similar to yours. When I want to use the vpn or access the webgui I want to access it via vpn.site.com. If I want the rest of my other containers I want to go to www.site.com/whatever

Link to comment
22 minutes ago, Ding Dong Del said:

 

I only use duckdns because I only have a dynamic IP address through my ISP (both domain names point to the same IP address).

You can use your own Dynamic DNS provider or hostname(s) assuming you can set up the relevant DNS entries.

 

so I dont have hostnames set up, but my domain points to my IP, and I have www and vpn subdomains

 

I changed my nginx.conf to (sites-config/default server also listens on 4430):

stream
{
    map $ssl_preread_server_name $name
    {
        www.example.net fred;
        vpn.example.net barney;
    }

    upstream barney
    {
        #openvpn container
        server 192.168.187.10:9453;
    }

    upstream fred
    {
        # upstream nginx virtual hosts such as sonarr, radarr, nzbget, etc.
        server 192.168.187.10:4430;
    }

    server
    {
        listen 443 so_keepalive=on;
        proxy_pass  $name;
        ssl_preread on;
    }
}

what Im expecting is that when I go vpn.example.net I get taken to openvpn webgui, but if I go to www.example.net/whatever I get one of my other containers. Correct expectation with the current config? Or is there something I need to change?

Link to comment

Going to mydomain.duckdns.org seems to take me to the unraid webgui instead of going through lets encrypt. I've been playing around with the settings as mentioned in the last few pages but i can't seem to get this working. I changed most of it back to what i had before. Here's what it is right now. I feel like it has to do with Unraid's HTTP port being set to 80 by default but i've tried changing that to 8008 and that didn't work either.

 

 

 

3.PNG.9f35829fbcea925fa0ef1545564936cd.PNG2.PNG.85ff33a781ec492080d0aafcfebac6eb.PNG1.thumb.PNG.80d3367ce55bf293aee36cfbdfb9aa15.PNG

Edited by Invincible
Added pictures of current settings
Link to comment
11 hours ago, Nem said:

is there a way to put openvpn access server's webgui behind an nginx reverse proxy?

 

I would strongly recommend against that for security reasons. VPN is considered pretty secure because it uses a certificate to authenticate. The web gui on the other hand only uses a password that can be brute forced. Once hacked, they can create their own cert through the web gui to get into your LAN

 

Once you create the user cert, you shouldn't need to access the web gui remotely. If you really need to, you can vpn in, and then access the gui

Link to comment

Hey guys I got mine finally working, however it's giving me NET::ERR_CERT_COMMON_NAME_INVALID when I am accessing the website from chrome. Is LE giving me a bad cert? 

 

Quote

ErrorWarningSystemArrayLogin


[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donations/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
2048 bit DH parameters present
SUBDOMAINS entered, processing
Sub-domains processed are: -d www.xxxxxx.duckdns.org
E-mail address entered: [email protected]
Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created
usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: argument --cert-path: No such file or directory
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xxxx.duckdns.org
http-01 challenge for www.xxxxx.duckdns.org
Waiting for verification...
Performing the following challenges:
http-01 challenge for xxxx.duckdns.org
http-01 challenge for www.xxxxxx.duckdns.org
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/xxxxx.duckdns.org/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/xxxxx.duckdns.org/privkey.pem
Your cert will expire on 2018-04-23. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size

 

Link to comment
11 hours ago, Ding Dong Del said:

 

@Nem - that's pretty much what I get when using my setup.

 

 @Ding Dong Del Ive finally managed to get ovpn-as webgui running through a reverse proxy by just using a subdomain and another server block in the config. But Im also intrigued by your use of the same port for both https and vpn traffic. I'm wondering why you chose to use hostnames/streams/subdomains to redirect traffic instead of using the port share feature of ovpn?

Link to comment
2 hours ago, aptalca said:

 

I would strongly recommend against that for security reasons. VPN is considered pretty secure because it uses a certificate to authenticate. The web gui on the other hand only uses a password that can be brute forced. Once hacked, they can create their own cert through the web gui to get into your LAN

 

Once you create the user cert, you shouldn't need to access the web gui remotely. If you really need to, you can vpn in, and then access the gui

 

@aptalca I'm pretty new to using VPNs so to clarify: (assuming I'm using a weak admin password for ovpnas) if someone brute forces my password and gets into the webgui theres a section where they can upload their own SSL certificate, but isn't that certificate only used for the web interface, not the actual VPN connection? How would my LAN be compromised in that case? Or do you mean they can now change my server config and redirect traffic?

 

I guess all of this can be prevented anyway with a strong password for the admin account...?

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.