Unifi Controller On Vultr Or Other

scottalanmiller

@brrabill said in Unifi Controller On Vultr Or Other:

Pretty much the same here.

As @scottalanmiller keeps telling me, it's just natively secure. (Linux, that is.)

The OS is, yes, but he's asking about Unifi.

BRRABill

@scottalanmiller said in Unifi Controller On Vultr Or Other:

@brrabill said in Unifi Controller On Vultr Or Other:

Pretty much the same here.

As @scottalanmiller keeps telling me, it's just natively secure. (Linux, that is.)

The OS is, yes, but he's asking about Unifi.

Considering he was mentioning things to also secure the OS, I think it's a package deal.

dbeato

I have one in Vultr and one in Google Cloud. I setup one behind Cloudflare and the other one has let's Encrypted. When I used the captive portal even with the let's encrypt SSL certificate it would not work properly as it would use the self signed SSL instead of the installed one. I also use fail2ban but that's it.

JaredBusch

@nashbrydges said in Unifi Controller On Vultr Or Other:

@jaredbusch said in Unifi Controller On Vultr Or Other:

Zero captive portals. But I have no idea why being on-site or off-site would affect that.

The reports I've read were related to the AP only talking back to the controller every 1 or 2 mins which caused delays in allowing new guest authorizations to connect to the internet. That's why I was hoping someone who has a remote controller with guest portal setup could confirm if they are also seeing this.

Do you realize how stupid this sounds? What AP manufacturer would have a guest portal that took 2 minutes to authenticate?

It does not work that way. Now with a huge AP network, yes, it will take time for all AP to see the authorization. But the AP they are connecting through will immediately let them connect.

JaredBusch

@dbeato said in Unifi Controller On Vultr Or Other:

When I used the captive portal even with the let's encrypt SSL certificate it would not work properly as it would use the self signed SSL instead of the installed one.

This is the issue that I never bothered to resolve when I was testing. It shows the correct DNS name in the pop up on iOS devices, but the actual cert is still the self signed cert.

Mine is behind a proxy server, not directly on the internet, and I never bothered to troubleshoot.

NashBrydges

@jaredbusch said in Unifi Controller On Vultr Or Other:

@nashbrydges said in Unifi Controller On Vultr Or Other:

@jaredbusch said in Unifi Controller On Vultr Or Other:

Zero captive portals. But I have no idea why being on-site or off-site would affect that.

The reports I've read were related to the AP only talking back to the controller every 1 or 2 mins which caused delays in allowing new guest authorizations to connect to the internet. That's why I was hoping someone who has a remote controller with guest portal setup could confirm if they are also seeing this.

Do you realize how stupid this sounds? What AP manufacturer would have a guest portal that took 2 minutes to authenticate?

It does not work that way. Now with a huge AP network, yes, it will take time for all AP to see the authorization. But the AP they are connecting through will immediately let them connect.

You realize I said "connect to the internet" right? Of course the AP sees them right away but the response of the entire chain, from user first launching web browser to getting "agree ToS" to clicking "agree" to being allowed to access the internet has been reported to take, on the high side, up to 1 to 2 mins to allow internet access. These reports are only when a remotely hosted unifi controller is being used with captive portal. Some have resorted to moving the controller locally, using the cloud key, or simply living with it. Since I do not use a remote controller, I have no way of verifying but installing this for a client, seems like the logical thing to do to verify if people who use remote controllers are seeing the same issue. If not, awesome! Due dilligence is part of the job.

Thanks @JaredBusch

JaredBusch

@nashbrydges said in Unifi Controller On Vultr Or Other:

@jaredbusch said in Unifi Controller On Vultr Or Other:

@nashbrydges said in Unifi Controller On Vultr Or Other:

@jaredbusch said in Unifi Controller On Vultr Or Other:

Zero captive portals. But I have no idea why being on-site or off-site would affect that.

The reports I've read were related to the AP only talking back to the controller every 1 or 2 mins which caused delays in allowing new guest authorizations to connect to the internet. That's why I was hoping someone who has a remote controller with guest portal setup could confirm if they are also seeing this.

Do you realize how stupid this sounds? What AP manufacturer would have a guest portal that took 2 minutes to authenticate?

It does not work that way. Now with a huge AP network, yes, it will take time for all AP to see the authorization. But the AP they are connecting through will immediately let them connect.

You realize I said "connect to the internet" right? Of course the AP sees them right away but the response of the entire chain, from user first launching web browser to getting "agree ToS" to clicking "agree" to being allowed to access the internet has been reported to take, on the high side, up to 1 to 2 mins to allow internet access. These reports are only when a remotely hosted unifi controller is being used with captive portal. Some have resorted to moving the controller locally, using the cloud key, or simply living with it. Since I do not use a remote controller, I have no way of verifying but installing this for a client, seems like the logical thing to do to verify if people who use remote controllers are seeing the same issue. If not, awesome! Due dilligence is part of the job.

Thanks @JaredBusch

Again, not how it works. there is no lag or delay. If there was this product would be shit and no one would use it.

I do have a remote controller, i have tested this. I have never had a delay getting access to the internet.

NashBrydges

Anyone have a working Nginx config they can share? I keep getting the websocket error and immediate disconnection when I login. I've tried a number of configs I found online but nothing seems to allow me to successfully login without being logged out right away. Here is my current conf.

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

server {
  listen 443 ssl http2;
  server_name mydomain.com;
  
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Content-Type-Options nosniff;
  add_header Referrer-Policy strict-origin;
  add_header X-Frame-Options "SAMEORIGIN";
  ssl_stapling on;
  ssl_stapling_verify on;
  server_tokens off;

  ssl on;
  ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
  ssl_session_timeout 5m;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384';
  ssl_ecdh_curve secp384r1:secp521r1;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  proxy_cookie_path / "/; secure; HttpOnly";

	location /wss/ {
		proxy_pass https://192.168.100.50:8443;
		proxy_http_version 1.1;
		proxy_buffering off;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "Upgrade";
		proxy_read_timeout 600;
	}
        
    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://192.168.100.50:8443;
        proxy_redirect off;
        
        proxy_read_timeout 600s;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
   }
}

Cert is working at least.
0_1528383687194_9076fb94-63b3-404c-ad27-eacbaf57b105-image.png

bnrstnr

@nashbrydges

server {
    client_max_body_size 40M;
    listen 443 ssl;
    server_name unifi.example.net;
    ssl          on;
    ssl_certificate /etc/letsencrypt/live/unifi.example.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/unifi.example.net/privkey.pem;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
    add_header Content-Security-Policy upgrade-insecure-requests;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options nosniff;
    add_header Referrer-Policy strict-origin;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass https://192.168.10.12:8443;
        proxy_redirect off;

        # Socket.IO Support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

    }
}

server {
    client_max_body_size 40M;
    listen 80;
    server_name unifi.example.net;
    rewrite        ^ https://$server_name$request_uri? permanent;
}

NashBrydges

@bnrstnr

Awesome! Thanks, that did the trick!

zachary715

Youtube Video