A bit of help with IP restriction with letsencrypt / dnsmasq

Hello all. I have moved everything I’m hosting to a single docker-compose file and using LSIO images where available.

The letsencrypt with the built-in proxy-confs is pretty brilliant, and it’s working fabulously except for one thing.

I want to proxy Synology’s Disk Station Manager as well as phpadmin, but I want them accessible ONLY via LAN and not over WAN.

Here is what I have done to try and achieve this.

In my router (I re-flashed DD-WRT just for dnsmasq), for the additional dnsmasq options I have:
address=/.domain.com/192.168.1.2 # IP of Synology NAS

Ports 80 and 443 are forwarded to 192.168.1.2 as well.

nginx runs on ports 80 / 443 (I’m only using 80 because I’m too lazy to type in https:// and that lets me auto-redirect HTTP to https). Below is the server block from the proxy conf (I am aware that the resolver / upstream assignment aren’t necessary, I just didn’t bother to remove them when I copied one of the existing files to make this one):

location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        deny 192.168.1.1;
        allow 192.168.0.0/16;
        allow 127.0.0.1;
        deny all;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_dsm dsm;
        proxy_pass http://192.168.1.2:5000;
    }

What I am seeing is that everything works as it should within the LAN; if I do a nslookup on the hostname it resolves to 192.168.1.2 as it should.

The problem is that it seems reachable outside the LAN as well; to test it, I turned WiFi off on my cell phone and hit the URL, but it still comes up.

I’m guessing I am just missing something in the allow / deny block above, but I’ve tried a few different things without much success. At first, I tried to only allow 192.168.1.0/24, but when I did that I couldn’t reach it at all.

Has anyone done this successfully?

I use the following in the “server” block and it works as intended

allow 192.168.0.0/16;
deny all;

I made the change and restarted the letsencrypt container, and there’s no change.

I’m guessing it’s something network related, but trace routes from my phone don’t return anything (probably * * * over and over, as it just says No Response until it times out - and that’s whet her I hit one of the “publicly served” URL’s or the two private ones. Probably a firewall somewhere between my phone and the server dropping the ICMP / UDP packets.

Without a route to see, all I could think to do was clear the storage / cache of the Chrome app, but that didn’t make a difference either. I don’t know if the site is cached somewhere or what but that’s all I can think of. Here is the full server block for reference.

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name dsm.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        allow 192.168.0.0/16;
        deny all;

        include /config/nginx/proxy.conf;
        # resolver 127.0.0.11 valid=30s;
        # set $upstream_dsm dsm;
        proxy_pass http://192.168.1.2:5000;
    }
}

I use this on all of my containers except 3; if i turn off wifi on my cell and browse to (in your case) dsm.domain.com i get a 403 which is the expected result.

traceroute just uses icmp to explore hops on a route, it’s not going to tell you if you’re blocking access (via tcp) to a webserver like nginx.

for an example, here is one of my confs

location / {
    allow 192.168.0.0/16;
    allow <my ipv6 subnet>;
    allow fe80::/16;
    allow 172.20.0.0/16;
    deny all;
    ...
}