Tags: Community

Creating a secure Home/Guest/IOT Wifi environment with Ubiquiti

As many of my friends and colleagues will know, I am a big fan of Smart Home/IOT technology – plugs, lights, sensors, cameras… I like automating things around the house – partly for security reasons, partly for reasons of making my life easier, but mostly because I enjoy working with technology! 🙂

However, I am well aware of the security implications of Smart Technology – and in particular the risks associated with placing devices onto a home network, where devices with personal information are regularly used.

In this post I’ll give an overview of how I am securing my network – with minimal effort… (All of this can be configured in under 10 minutes)

I’m using the awesome Ubiquiti Unifi nanoHD APs:

Ubiquiti equipment and software is AWESOME, especially if you want effective and easy to use control over your network, without having to use complex configuration scripts or a confusing GUI. There are a few things you can do to secure Smart Technology items, and also to create a secure environment for Guest Users, Children, and anyone/anything else you may wish to restrict in some way. The key features that help here are:

  • Separate Wireless Networks – I have a Wireless Network setup for my own devices, another for Smart Tech items, and another for Guest Users – these are best off separated and kept apart! (These are all broadcast from the same AP too – with no need for extra hardware)
  • Time based Wireless Network access – this is more for those with children, whereby you can have a Wireless Network that is available only between certain times.
  • Throughput Control – this allows a Network to be restricted to a specified total bandwidth throughput. Useful for ensuring one device/user/network does not overload your internet connection
  • IP range restrictions – this allows devices on specific Networks to be restricted when trying to access certain IP ranges or addresses. This is great for Guest networks – and can be used to ensure those Guest users can only access the internet for example. Many Smart Tech devices also require only internet access, with no need for them to communicate with other items on your network.

Configuration of all of the above is extremely simply using the Ubiquiti Controller – I’m running this on my own server, but the Cloud Keys are worth a look if you don’t have this option or want a dedicated device. Thankfully all of the above is just a few clicks in the Controller interface too – no need for any configuration, cabling, or code!

Separate SSIDs

This is very easy to setup – from the settings interface, browse to Wifi Networks, and then create the networks you require:

Ensure that for any IOT or Guest Networks you mark these as Guest Networks – as the security restrictions (IP based) then apply:

Time based SSID access

Again, this is a breeze to setup – on the SSID you want to restrict select, Edit (shown below):

You can then control the time on a schedule:

This setting is probably more for those with children who’s access they are trying to limit – unless you have devices you don’t want online at certain times.

Throughput Control

Throughput control is based on creating User Groups – with a throughput limit assigned to the Group. I have the following Groups setup:

Personally I think I am quite generous with my Guest users…

Next – we need to associate the Groups with a Wireless Network, so that the bandwidth restrictions are applied to that Network. To do this, go back and edit the Wireless Network:

Within the User Group section – select the required Group:

Now your Wireless Network has a configured throughput limit!

IP Restrictions

These are also very easy to setup, browse to the Guest Control section of the Settings Menu – and then add any IP ranges or addresses you want to prevent Guest Users (any Wireless Network marked as Guest) accessing:

I’ve left this default – any private address is restricted – so my Guest Users and IOT Devices can only access the internet, and are prevented from accessing anything else on my networks.

Hope this helps – until next time!

Introducing PowerScale – a community driven Smart Scale alternative!

As you may know, Smart Scale has been discontinued as of 31/05/2019. But – fear not, a community project now provides the same functionality. This project is the brainchild of Leee Jeffries (twitter/blog – well worth a follow/read for anyone working in the EUC space by the way!), and provides a simple to use solution, that provides a great replacement method that can save VM cost in Cloud Environments, with an on-premises control place.

PowerScale can carry out the following actions on VDAs:

  • Scheduled Machine Management
    • Working Hour Schedule
    • Outside Working Hours Schedule
      • Power On Machines
      • Power Off Machines
      • Scale Machines based on performance metrics
        • CPU
        • Memory
        • Load Index
        • Session Limits
    • User Logoff
      • Forced User Logoff
      • Two Message sent to users at specified intervals before shutdown
    • Graceful User Logoff
      • Wait for sessions to drain before shutdowns complete
    • Email on critical error
    • Testing only mode
      • Logfile generated on every run
      • No farm actions performed during test mode

You can download PowerScale here, and an installation guide is also available here.

XenDesktop Site Failover – asking the community…

Recently I’ve been doing a lot of work on large deployments that require active/active or active/passive setups, whereby options to fail over to a DR site are either required as part of the design, or presented as future enhancement to the customer. Most of these have been fairly open questions – “How can we achieve this?” for example. It’s a question that is almost completely subjective; it depends entirely on business needs, and what the available budget is.

Subjective elements aside, it is a much debated technical area, so I opened up a question on the MyCUGC forums to ask the community how they were going about this. I also tweeted the question out @jakewalsh90:

I based my question around the concept that is most common (certainly to me at least) – an active/active or active/passive design, with a primary site and a secondary (DR/Backup) site. This is without a doubt the most common environment type that I encounter, predominantly in small and medium enterprises up to around 5000 users.

The main purpose of this post is to summarize the elements (both technical and strategic) that could be considered, and the different options we can lean on to help achieve the desired results. And also, to highlight just how good the response from the Citrix Community was on this question!

Key Considerations

By far the most common point that came out of the discussion around this was – “it depends”. There are a great number of factors to consider for any solution like this, including:

  • Budget – what is affordable and achievable with our budget?
  • Connectivity – are we limited by latency/bandwidth/other traffic etc? Are we using Dark Fiber, MPLS, VPN etc?
  • DC Locations – if we are planning for a Secondary/DR site, is it likely this would ever be affected by an issue that took down our primary site? (Hurricanes, Floods, Earthquakes etc.)
  • Capacity – is this a full DR/Secondary solution or just a subset of applications and users?
  • Hardware – do we have the hardware to achieve this? Is it within our budget?
  • Software – can we do this within our current licensing or do we need an uplift?
  • Applications – are we replicating everything or just key applications? How will these applications perform in another DC? (Applications may have web/database dependencies based only in a single site).
  • User Data – are we replicating user data too? How are profiles going to be handled?
  • Failover method – are we utilizing a Citrix solution for this, or perhaps a product like VMware Site Recovery Manager? How is failover undertaken – automatic? manual?

Citrix Considerations

Aside from the many other factors affecting a question like this, our discussion focused on the Citrix technical elements aimed at DR/Failover options available. I’ve highlighted the key points we discussed, and gathered a number of resources that I think are helpful in discovering these further:

 

GSLB via NetScaler for StoreFront (Access Layer) – this was a common theme throughout the discussions, and there seems to be a general consensus that utilising GSLB on NetScaler is a logical way forward. Creating an access layer that utilizes NetScaler GSLB and StoreFront, whilst spanning the DC’s, will give a solution that is resilient and reliable, and won’t require complex replication/management. Dave Brett has written an excellent article on setting this up.

 

 XenDesktop Site with ZonesZones in XenDesktop are an awesome way to split geographically (or logically) separate resources, whilst maintaining the ease of management and reduced overhead of only having a single farm. Utilizing Zoning to form an active/active or active/passive solution is simple in configuration terms too. With Zones users can be automatically redirected to a secondary zone VDA during the failure of a their primary zone VDA.

 

Local Host Cache – as I am sure you are aware, Local Host Cache is now back in XenDesktop, and provides additional tolerance for database outages. LHC allows connection brokering operations to take place when the following issues occur:

The connection between a Delivery Controller and the Site database fails in an on-premises Citrix environment.

The WAN link between the Site and the Citrix control plane fails in a Citrix Cloud environment.

See https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-12/manage-deployment/local-host-cache.html for further details on LHC.

You can check to see if LHC is on by running the following PowerShell: Get-BrokerSite. I’m running 7.15 in my lab so it is enabled by default:

 

SQL Options – SQL is a key component of the FMA architecture – so any solution (with or without DR/Failover) needs a reliable solution for hosting Site Databases. Usually my go to solution is to mirror any databases using SQL Mirroring. AlwaysON Failover Clustering, and Always On AvailabilityGroups are both possible solutions – particularly given that Database Mirroring is being deprecated.

When DR is considered this opens up additional hardware and software requirements to provide suitable hardware and SQL Server licensing.

See page 101-102 of the Updated Citrix VDI Handbook for further information on SQL redundancy and replication options: http://docs.citrix.com/content/dam/docs/en-us/xenapp-xendesktop/7-15-ltsr/downloads/Citrix%20VDI%20Handbook%207.15%20LTSR.pdf

 

Using StoreFront to handle the Failover (Site/Delivery Controller Level) – From StoreFront 3.6 it has been possible to Load Balance Resources across controllers, allowing StoreFront to effectively handle failover between XenDesktop Farms. (See https://www.citrix.com/blogs/2016/09/07/storefront-multi-site-settings-part-2/ for more details on this)

This method allows us to have two XenDesktop Farms – and to publish identical resources which are then load balanced by the StoreFront server. Failover would only occur in the event that a Delivery Controller was unavailable in the primary site. This solution would still allow for a GSLB approach with StoreFront and NetScaler too.

The main disadvantage of this approach is the increased management overhead of the additional XenDesktop Farm, but this can be managed by having good practices in place.

This is configured in the Delivery Controller section of a StoreFront site – and requires both farms to publish the resources required for failover. See below – two Farms configured in the Delivery Controller section within a StoreFront site:

We also need to configure the “User Mapping and Multi-Site Aggregation Configuration”. Note that below I have configured all Delivery Controllers to for “Everyone” – but this may need to be adjusted in a production environment:

You will also need to configure resource aggregation as below. For failover, do not tick “Load Balance resources across controllers”. However, “Controllers publish identical resources” will need to be ticked so that identically named published applications or desktops are de-duplicated:

With this set, any resources published in both farms will be launched from the Secondary Site in the event that the Delivery Controllers in the first site fail to respond.

 

Application Level Failover using Application Group Priorities – it is also possible to use application groups with priorities to control the failover of applications. When you configure an application group in XenDesktop 7.9+ you are able to configure this:

Gareth Carson has a great blog post on this which explains the functionality in more detail.

In Conclusion…

Hopefully this post has been helpful in highlighting some of the considerations for a DR/Second Site scenario. And also, has helped to highlight some of the Citrix technologies and great community resources out there to help make the process a little easier. It’s been useful for me to ask the question and compile a post like this because I’ve had to look into the various technologies and find out more about them in my own lab before writing this… until next time, cheers!