Professional Remote Access for Your Smart Home. Part 3

Professional Remote Access for Your Smart Home. Part 3

Previous part: Professional Remote Access for Your Smart Home. Part 3

Virtual machines tend to have dynamic MAC addresses by default, and for historical reasons involving yellow boxes that slid into server racks the Kemp license is tied to your MAC address. Make sure you set it to static so that Kemp doesn't suddenly stop working in the future if the MAC address changes. When you first start the virtual machine it will try to get an IP address from DHCP. You can log into the command line and change this to a static one. The default username is "bal "and the password is "1fourall". These are both displayed at the console for you. I'm going to set the IP address on mine to I'll leave the default gateway and DNS servers at current values, and I don't have a proxy. Now we can connect to it using a web browser at the address displayed. 

Click through the licence agreement and now we'll need to log in with our Kemp account to get a licence. Select "Free LoadMaster" and off you go. Next we pick a password for the device. This isn't your Kemp account - this is going to replace the default password on the "bal" account, because default passwords are bad. Now we can log in. Welcome to your free load balancer! There are a few admin tasks for you to do under "System Configuration" like changing the hostname, configuring a time server, email alerting, and so on. I'm going to skip all of that because this isn't a Kemp deep-dive or best practices guide, and there are a lot of options in here. What we're interested in is under the "Virtual Services" menu heading. We're going to "View / Modify Services" and click "Add New". It asks for a virtual address. This is a second IP address we're going to give to Kemp to host access to openHAB. This is where our bodyguard is going to live. 

Also check out: 3950x vs 5950x

Our load balancer's administrative address is I'm going to make this address dot 11. I'm going to set the port to 443, which is the standard port for HTTPS encrypted websites. I'll call it "openHAB" and click "Add this Virtual Service". Now we're listening on port 443 and it's defaulted to an HTTP service type, but the moment it isn't actually encrypted. To enable encryption we come down to "SSL Properties" and "Enable SSL Acceleration". We'll get a warning about not having a certificate. That's fine - we'll sort it later. A couple of extra buttons to click: "Reencrypt" to make sure traffic between Kemp and openHAB is also encrypted. This won't actually work yet, and isn't strictly necessary; but it is more secure - especially if you deployed Kemp in a DMZ network. We're also going to deselect TLS 1.1 because that's old and you shouldn't need it. Now we're going to head to "Advanced Properties" and change this "Not Available Redirection Handling" to "503 Service Unavailable". 

This will help us see if we've done things properly because at the moment Kemp doesn't know how to talk to openHAB. If we try to use it,, nothing will happen. Changing this setting tells Kemp to talk to us and tell us openHAB isn't available; so if we see that message we know Kemp is working, even if openHAB isn't. Finally, we're going to click this button to add an HTTP redirect. This means any unencrypted traffic is going to be told to come back as an encrypted connection. If you click back you'll see that it has actually added a second virtual service on port 80. You can quickly test this out if you open another tab and browse to the IP address of your virtual service. You'll see it get redirected to HTTPS and tell us the service is unavailable, which is exactly what we told it to tell us because it can't talk to openHAB yet. 

The next thing we need to do is get some ports forwarded through our firewall and register ourselves a certificate so we can get rid of these security warnings. If you don't know how to set up port forwarding you'll need to have a poke around inside your router settings or read the manual, because they're all different. Look for something like port forwarding, port mapping or NAT (which is network address translation), or maybe even PAT (which is port address translation). I'll pull up a quick TP-Link example. They call it "Port Forwarding" under "NAT Forwarding". You'll need two rules. The IP address you're forwarding to in each case is the IP address of the virtual services we created in Kemp. 

Read more: gtx 1650 vs 1650 ti

The protocol will be TCP. For the first rule the port number will be 80, and for the second rule the port number will be 443. These map to the two virtual services in Kemp. If it asks for two port numbers (external and internal in this case) use the same number for both. Now we've got our DNS record pointed at our router and our router forwarding the ports to Kemp. If I try to browse to my DNS name ( in my case) from the internet I should get connected to Kemp and receive that "Service Unavailable" message. I'll also get a security error because of the default certificate, which we'll deal with now. 

If you've been watching the channel for a while you may remember I did a video about getting free certificates from Let's Encrypt. Well our Kemp LoadMaster has a built-in Let's Encrypt client so it's time to put that into practice. We'll go to "Certificates & Security" then "Let's Encrypt Certs". Click "Register Account" to connect your LoadMaster to Let's Encrypt. If you add your email address it'll warn you if your certificate is about to expire. 

Now we can request a certificate. I'll call it openHAB. This is just a name to identify it in Kemp. The important name is a common name, because that needs to match the DNS name you pointed at your router. I'm using for this. Where it says "Select a VS" we'll choose the one ending in 80. The rest is optional so I'm going to go ahead and request a certificate. That's it! We've got a publicly signed certificate and Kemp is going to keep it up to date automatically. It's amazing how easy this process is. Setting up a certificate used to be a convoluted task where we generated requests and keys, submitted them to a public authority, went through a validation process, handed over a word of cash, and then downloaded the response and combined it all together. Now it's a button click. You've gotta love that! Back to virtual services and we're going to assign our new certificate. We can click the "Add New" button here, assign the virtual service to your openHAB certificate, and click "Save Changes". Done. Now if you browse to it from the internet there's no security warning because we have a valid certificate, issued by a trusted authority. Now we're encrypted let's get some of that multi-factor authentication going on.

Read more: RX 5600M vs GTX 1660 Ti

 If you've already got an identity provider ready to go, then good on you - use that. For those who don't we're going to install FreeRADIUS for a simple username and password. In my previous video I installed openHAB on both Windows and Linux. I'm going to use our Linux server to host FreeRADIUS. I think there's a build for Windows, but it's definitely more common on Linux. If you're using a Windows server then the Network Policy Server role is Windows' own RADIUS server so you can use that or you can install Active Directory and set up a full domain. I had installed this on CentOS Stream so it's "sudo dnf install freeradius". 

On Ubuntu it would be "apt" instead of "dnf". Substitute your package manager in as appropriate. Once that's installed we have a few config files to edit, because Linux. These are in /etc/raddb. The first we'll look at is clients.conf. This is where we specify which devices are allowed to talk to FreeRADIUS. By default it has a localhost client which allows the server to query itself internally using the secret "testing123". this is just for local testing and won't work over the network, but that's also fine for what we need so I'll make a note of the secret and leave it as-is. When you're doing this for real, change that secret; because even though it's not going over the network that default is really bad. I'm going to leave that file alone for now and jump into our users file. Here I'm going to do something equally naughty and create a user account with a terrible password. 

Again, pick a better one. We need to add a line in the format username "Cleartext-Password := " and the password in quotes. Another thing to put into your bag of security enhancements: regardless of what password is used it's really not ideal to be storing passwords in cleartext like this. It would be much better to both salt and hash your passwords, and store the resulting value; because that way if someone gets hold of this file they can't easily tell what your password was. If you want a video on good password storage practices, put it in the comments. For now that's all the configuration we're actually going to do - just adding that user account. I'll save, then run "systemctl enable radiusd" to make sure the service is enabled for automatic start-up, and then "systemctl start radiusd" to start it.

Read more: Intel i7-1165G7 vs i7-1065G7

 That's our rubbish authentication factor, let's get the good one! For this we're going to head over to and sign up for a free trial. You'll get a time-limited trial of their higher tier offerings, but once it's up you can stay on the free plan for up to 10 users; and it's perfect for what we need. I'll let you work your way through the sign-up. I've already got an account so I'll skip to the admin console. The first thing you probably want to do is check your billing. It'll default into a trial of one of the paid plans, but you can go down here and set it the free version. From memory I think it changes to that automatically at the end of your trial feel. Free to play with more of the advanced features if you'd like to. Personally, with these freemium type offerings I like to set it straight to the free edition if that's all i'm intending to use so don't end up accidentally configuring something that relies on advanced features, and end up with broken features when the trial ends. 

Next we'll need to create a user account. You can do that here under "Users" > "Add User". The important thing is that the username here needs to match the username we added into FreeRADIUS or whichever other identity provider you're using. Once the user is added we can click "Send Enrollment Email" and Duo will send instructions to get the account set up for multi-factor authentication using the mobile app. That's done. Now we need to set it up to work with FreeRADIUS. To do that, come up to "Applications" and "Protect an Application". Here you've got a list of all the things Duo works with, and links to the documentation for each. If I filter for RADIUS and click "Protect" that will set up the application in Duo. 

We can change the name from RADIUS to openHAB to make it a bit more obvious what this is for; then we'll want to take a look at the documentation. How this actually works is by installing an application called the Duo Authentication Proxy that sits between Kemp and FreeRADIUS. This works on Windows or Linux. In our example we're using Linux but I'll quickly show you on Windows as well. The download links and all the information you need is on the documentation page linked from your RADIUS application. If you closed it by accident come back to your applications, click on the openHAB RADIUS one, and there's a link at the top.