nginx http proxy -> 3480

akbooer,

Since the beginning of having openluup here, I installed a nginx proxy with a login/password auth to gain access to openluup/altui from outside… everything works fine since the last update I did as you know for the timer bug also!

The issue i’m having it’s nothing is send back. just a white page! Looks like openLuup/ALTUI refuse to send out traffic using the proxy.

Sorry, this is way out of my understanding. It might be an AltUI thing, rather then an openLuup one… have you tested on an actual Vera?

To understand correctly. All the “http” output including also the HTTP server itself… it’s coming from ALTUI or openLuup ?

The HTTP on port 3480 is part of openLuup. This is used by AltUI for status and command queries. When AltUI is talking to an openLuup installation, all communication is done through that port. This has required some modificationof AltUI by @amg0, since Vera also talks on port 80 for some things, and also on a high-numbered port for others (specifically, so-called HAG requests.)

DesT, did you ever get this to work? I’m consider this approach with nginx as a reverse proxy to get access.

yeah bro… using that since a while with a login and password to access it!

works like a charm :wink:

Would you mind posting your nginx configuration information (of course removing any sensitive information)? You are using https plus the password? And if you use https, then did you use a self-signed certificate or go with something like Let’s Encrypt? I may start with self-signed, but it gets ugly with browsers, so I will next go ahead and pay for a DDNS name and then use Let’s Encrypt. Lots of questions - hope you don’t mind. Thanks!

Yeah no prob…

The config is very easy:

I’m having a little VM that just handle nginx and send the traffic to the openLuup box.

location / { auth_basic "Restricted"; auth_basic_user_file /var/www/html/.htpasswd; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://VERAIP:3480; }

I’m currently not using SSL for the moment but nginx is behind the firewall and i’m running fail2ban also to block those who try the box :wink:

thanks - got it to work. I’m using SSL and the password. I paid for the domain so I could use Let’s Encrypt. My browser is now happy. I would prefer to have 2 factor authentication. I’ll have look at that as my next project.

This looks really useful, but is way outside my expertise. Would it be possible to get a short description for dummies (like me) to describe the overall approach and get it going?

I’ve never used openLuup from outside my LAN (except via HomeWave.)

I could add it as a sticky post. Thanks if possible.

I used this tutorial, it’s very good: https://community.openhab.org/t/using-nginx-reverse-proxy-authentication-and-https/14542

Note that I am a bit uncomfortable with this as then you have a port open to the Internet at all times. Need to keep everything up to date as far as security. It’s also only as good as the password. Currently I have Google Wifi so I can turn the port forwarding off and on remotely as desired. I will be taking a look at fail2ban that DesT mentioned.

Health warning noted! Let us all know how you get on with fail2ban too.

Many thanks.

A little further in this vein, I’m mulling over adding the oauth2_proxy (https://github.com/bitly/oauth2_proxy). Then I don’t have to muck around with my own separate password file. And then it appears that it wouldn’t be too hard to have an Alexa skill that would “talk” to openLuup through the nginx reverse proxy with this authentication. And finally that would let me get rid of the somewhat less than reliable ha-bridge.

Anyone been done this path? Any advice? Thanks…

I have the oauth2_proxy running. It is easy to use the Google service for the authentication. There is a systemd service file to wrap around the oauth2_proxy process which works reasonably well. It is a bit chatty in the syslog - every request is logged. I may take a look at trying to tone that down a bit.

I did have one issue with nginx: I have openLuup come up after a delay since it is waiting for the Z-way server to come up fully. Default nginx doesn’t like this as it comes up earlier and thinks the openLuup is dead - and then will redirect. As far as I can tell from the documentation it should have fixed itself once openLuup came up, but it didn’t appear to work for me. I’m going to try to disable the health checks (basically max_fails and possibly fail_timeout) to see if that will work around this. Or figure out how to delay nginx startup until openLuup is up.

Now that this is up, I may tinker with modifying the openHAB Alexa skill (https://github.com/openhab/openhab-alexa) to one that talks to openLuup.

jswin788,

Can you post some screenshot of what looks like the “authentication” prompt ?

Looks like this. Once you click it, you get a prompt from Google asking about which email account. After you select your account, it asks for some permissions (first time only), then you get to the page you requested originally.

Are you able to use the Google Authenticator using 2FA ?

I’ll have to try it. However, as far as I can tell, that’s for the initial login to Google in the browser (for the session). Since I’m already logged in when I go to my site, I’m not re-entering my Google password. If I’m logged out of Google, and try to go directly to my site, I suspect then I would see the 2 factor authentication if I have it enabled. Let me see…

It may also be possible to leave basic authentication enabled when running the oauth2_proxy, so I’d have to login to that, then have Google authenticate me for extra security.

In any case, I’m in a heap of trouble for lots of places if my Google account is hacked…

I mean Google 2FA only… not using a Google account…

Are you asking about not using oauth2_proxy and just using 2 factor authentication? I imagine this is possible, but I haven’t looked at it. The basic authorization is pretty good, but occasionally gets irritating with multiple password requests. The oauth2_proxy is easier to use, but once you have that, then you have to use an oauth provider account. I think I’m going to stick with the oauth2_proxy.