Tag: Security

Ubiquiti USG: Quick & Easy Remote Access VPN

Hello World!

When I decided to purchase and install a Ubiquiti USG-3P security appliance, which you can read about here, one of the determining factors was that I could configure VPN service for remote connectivity. As I use Dynamic DNS (DynDns) with the USG (read about that here), I have a reliable VPN url that is always available.

Whenever you put “Quick & Easy” in the title of anything, the expectation is that the process is not difficult and does not take all day. Ubiquiti has made the process very simple, I’ll outline the steps below.

Step 1.  Configure the local Radius server

This first step is located under the Settings -> Services -> RADIUS -> Server   within the Unifi Controller software. Turn it on and set your Secret and you are good to go!

Step 2. Configure your Radius (VPN) User

This second step is located under the Settings -> Services -> RADIUS -> Users   within the Unifi Controller software. Turn it on and set your Password and you are good to go! Notice I left the VLAN blank. If I was using the USG as a switched Layer 3 device this would need to be filled in. As it stands my USG is basically running as a transparent firewall.

Step 3. Build your VPN Network (VPN Profile)

This third and final step (on the UBNT side) is located within the Settings section under Networks. You will create a new network and select Remote User VPN as the purpose. In my case I selected an L2TP  Server, you could select PPTP as well, but L2TP works for my purposes. You’ll then configure your Pre-Shared Key (PSK) and define your VPN subnet. I recommend making this network small and keeping it on a network convention dissimilar from your internal networks. Configure your Name (DNS) server(s) and other options and then select your Radius profile. In my case the simple Default profile was all I needed. Within the Radius profile configuration you could add an external Radius server if you have one in place currently. If that is the case the first two steps are not necessary.  The MS-CHAP v2 requirement is checked by default and you should use it for security.

At this point, we are done with our Ubiquiti configuration! That means it is time to move on to the client side. In my case that means Windows 10. There are L2TP/PPTP configuration guides out there for Mac and Linux as well but since I am using Windows, that is what I’ll cover.

Step 1. Go to the VPN Configuration Screen

In the image below you’ll see the VPN configuration screen that is under Settings -> Network & Internet -> VPN from here you can Add a VPN Connection. Once your connection is added you’ll see it in the list (as shown below) and also in the network status icon on your Windows taskbar (Windows 10).

Step 2. Configure the VPN Profile

Configuring the VPN profile for Windows 10 is very straightforward. You’ll need the public address of your USG (or your Dynamic DNS url) and you’ll need the Pre-Shared Key (PSK). You’ll also need (optionally) your username and password. If you don’t enter your username and password (shown in the image below) you’ll be prompted every time you connect.

Step 3. Connect

To connect to your VPN in Windows 10, select the network status icon in the task bar (usually a computer screen for wired or a wireless signal graph for wireless) and click on the VPN connection at the top of the box.

If you entered your username and password into the configuration page you should not be prompted for them, if you did not, you will need to enter them when prompted. Once connected, you’ll see the status above.

When I show my connection status I can see the VPN settings that I configured earlier (shown below).

In closing, this really is a quick and easy process. If you need easy and reliable remote access it is definitely something to consider. Also worth considering is that we are doing this configuration with PSKs and not with certificates. There are security considerations to take into account here.  With all of that said, I would 100% choose this option over users accessing systems remotely via the questionable applications that exist in the software client remote access space today.

I hope this helps someone! Questions? Comments? Post them below.

-Justin

Advertisement

Forgive Me Cisco for I Have Sinned (And I Liked It!)

Hello World!

If you’ve read any of my other posts, you have no doubt figured out, that I am a Cisco guy. Cisco’s products have kept me gainfully employed for many years (and hopefully for many years to come). I enjoy their technology but I also know they aren’t the only game in town.  I am also painfully aware of what it costs to play their game.

The Problem

Recently, my home network/lab Cisco ASA 5506-x died. This was a long expected outcome from a hardware clock malfunction that Cisco discovered a few years ago, you can read more about it here: https://www.cisco.com/c/en/us/support/web/clock-signal.html. If you have SmartNet support on your products this is a problem, but a covered problem. If, like me, you bought your products on Amazon or Ebay, you are screwed.

The Research

When the 5506-x died, I considered buying a Cisco Next Generation Firewall (NGFW) as a replacement (the 1010 would probably work). I’m not made of money and the thought of paying $800 on the gray market (or even from CDW) had me less than excited. I also considered buying a Sonic Wall, Juniper, or Palo Alto appliance but I don’t have support contacts/contracts for those brands and I want to be able to patch them (this is not a problem with Cisco). I then considered building an Endian or PfSense firewall but by the time I got the right appliance I would be out as much money as the Cisco option discussed above. With my home internet speed being over 100Mbps, I was going to need a very powerful box.  In case you are wondering what it takes to build a custom firewall, please see this link for sizing guidelines: https://www.firewallhardware.it/en/firewall-hardware-sizing-guide/. I was quickly running out of viable and reasonably professional options. It was then that I looked at my wall and found one more.

I started using Ubiquiti’s Unifi wireless access points a couple of years ago for a family business. I was impressed by the hardware and actually really liked the controller software as well. Being able to extend SSIDs across multiple access points without giving up backhaul bandwidth (assuming you have LAN drops where you need them) is a professional feature and one that I take advantage of often. Consumer grade multi-unit systems dedicate channels (and thus a portion of total throughput) to the backhaul communication between the “access points” and the base station. I also like the Ubiquiti price. The 802.11ac access point above, was $99 on Amazon. When it came time to put access points in my home the Ubiquiti option was an easy choice to make.

“If their access points are great, maybe I should give their firewalls a try.”

The Decision

The Unifi Security Gateway (USG) is a powerful platform. The architecture follows the versatile Edge architecture that Ubiquiti was originally known for. While the Edge platform devices have individual web interfaces and operate autonomously, the USG registers to and is managed by the Unifi Controller. Luckily, the USG does still include SSH/Console access to the powerful Ubiquiti CLI. The CLI is a cross between Unix, BSD, and Cisco’s IOS but once you understand it, it is very useful.

There are currently three (3) models of the security gateway available…

  1. USG
    • 3 1G ports
    • $138 + shipping on Ubiquiti Store
  2. USG‑PRO‑4
    • 4 1G ports (2 with dual-personality SFP ports)
    • $344 + shipping on Ubiquiti Store
  3. USG-XG-8
    •  8 10G SFP+ ports
    • $2,499 + shipping on Ubiquiti Store

I chose the USG. Small but mighty! Price aside, this little box will handle more bandwidth than I can currently throw at it*. With that said, the price is nice too.

*This is without IPS (currently beta) enabled. If you enable IPS the hardware offload is turned off and all packets are processed via software. This limits the throughput of each device as follows…

  1. USG: 85Mbps
  2. USG-Pro-4: 250Mbps
  3. USG-XG-8: 1Gbps

With the above numbers, I will probably be replacing my USG with a USG-Pro-4 (or whatever the next generation option is) in a few months. I want to take advantage of the IPS functionality but don’t want to limit my Internet bandwidth. Currently, this is a minor concern.

The Configuration

Setting up the USG took more time than you might expect. Part of this was my architecture; Ubiquiti likes their routing devices (the USG in this case) to be the end-all/be-all Layer 3 device in the network. In my network, that is not the case. I traditionally run my firewalls in transparent mode and use a Layer 3 “core” switch to handle the inter-vlan routing and segregation of traffic. I want the firewall to terminate the WAN/Internet connection and secure the connection as well as handle the NAT/PAT responsibilities but I want it to end there. My logical configuration is laid out in the image below.

 

As you can see from the logical diagram above, my USG sits in the “normal” firewall position between the provider NIU and my LAN. I am handling all VLAN routing and inter-VLAN routing on the 3750x. On the switch I have a static default-route pointing at 10.10.0.230 (the LAN IP of the USG) (shown below).

ip route 0.0.0.0 0.0.0.0 10.10.0.230

In the USG I have routes going back to the my 3750x (10.10.0.254) for the networks configured there (shown below).

static {
        route 10.10.10.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }
        }
        route 10.10.30.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }
        }
        route 10.10.100.0/24 {
            next-hop 10.10.0.254 {
                distance 1
            }

Finally I have a NAT rule in the USG allowing everything that goes out of eth0 (WAN) to be source NAT’d accordingly (shown below). This works well as I have a DHCP connection from my ISP.

rule   type  intf     translation
----   ----  ----     -----------
6001   MASQ  eth0     saddr ANY to X.X.X.X
    proto-all         sport ANY

Conclusion

I admit it is still early (as I’ve only had the USG in place for about a week), but I am impressed by that little box. No loss in throughput and I enjoy having the Internet statistics on my Unifi mobile application. The USG wasn’t my first choice but the more I do with it the more I am convinced it was the right choice for my environment.

Below are a few quick additions that I didn’t get to cover in this post, I plan on adding posts for these features later…

  • NAT/PAT for Cisco Unified Border Element (CUBE)
  • Dynamic DNS (DynDNS) native integration
  • Quick and Easy VPN Client configuration

-Justin

 

 

 

 

 

CUCM: TLS 1.2 and Legacy Phones

Hello world!

Today’s post will be quick and dirty but hopefully useful.

In Cisco Call Manager (CUCM) version 11.5(1)SU3 support was introduced for Transport Layer Security (TLS) versions 1.1 and 1.2. Prior to this release 1.0 was the only supported version. With security being the driving factor in much of the IT world these days, there is a push to secure everything to the highest available level, that includes the Collaboration environment. I have many customers that want to take advantage of the higher TLS version levels and that is a good thing, but there are gotchas.

If you know anything about Cisco IP phone communications you know that several services; and specifically the Corporate and Personal directory service are pre-configured applets that run between the phone and CUCM. In the case of the directory service(s) they talk using 8443 which is a secure port and thus uses a certificate to communicate (along with the Trust Verification Service (TVS)). That certificate is directly encrypted with the help of TLS. Because support for the newer/higher TLS versions has only recently come into play there are several generations of IP phones that do not support anything above TLS 1.0 (or 1.1 in some cases). This list of legacy endpoints includes the 7900 series and Cisco’s previous “Cadillac” the 9900 series as well as others.

If you have legacy endpoints and change your TLS version to something above 1.0 you will notice that the directory services on those endpoints will fail with a “Host not found” error. What is actually happening involves a failed TLS handshake between the phone and the Trust Verification Service (TVS) on CUCM. Because the phone cannot communicate with the TVS using TLS 1.2 the handshake fails and the directory service cannot be accessed.

So what are your options?

  1. Replace your legacy phones, there is always a financial fix and this is it.
  2. You can manually create a directory service that talks HTTP and assign it to the phones. You could make this an Enterprise Subscription if you want everyone to use it. The URL that you should use is: http://YOURCUCMFQDNorIPHere:8080/ccmcip/xmldirectory.jsp. Since this is an HTTP service you can use the IP instead of the FQDN. This will allow the service to function whether name services are functional or not. This will require user training but may make the most sense depending on the environment.
  3. Revert to TLS 1.0. This sounds easy, but there are gotchas here too.

The gotchas of going back…

Switching from TLS 1.0 to TLS 1.1 or 1.2 (If you are going to change, go to 1.2) is a relatively straight forward process. You log into the platform CLI of your CUCM publisher and any subscribers and issue the following command set tls min-version 1.2. When you enter this command you will be asked to confirm and once confirmed (with yes) the system will restart. This happens immediately and should only be done during a maintenance window.

Switching back from TLS 1.2 to 1.0 follows the same steps with the same command and the same reboot process. However, when you switch back from a higher TLS version to a lower TLS version, anything that was encrypted using that higher TLS version becomes invalid. This includes certificates (which automatically regenerate) and also the application UI password store  (including your CCM Administration credential). This password must be reset from the CLI and changed to something different before you can log into the system again. Note that this does not change your Prime License Manager (PLM) admin password if co-resident with your CUCM.

Security is important and continually making our security better is the only way to prevent incidents. With that said, proper planning will stop security changes from turning into outages.

Cisco’s TLS 1.2 Compatibility Matrix: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/Compatibility/TLS/TLS1-2-Compatibility-Matrix.html