Cisco Expressway – The First Step Towards a VPN-less Enterprise – Part 1

As many of you already know, there are a plethora of cloud based, on-prem, self-hosted, shared hosted, anywhere hosted collaboration platforms to pick from. From Skype to Slack, from Jabber to Lync, all we really want is a robust, secure, easy to use application that enables collaboration with our team. Is that too much to ask?

If any of you are unfamiliar with using Cisco’s Jabber application, I ask that you keep an open mind and read carefully. Where else can you place calls, send messages, check voicemails, and group chat with your team, all from the the security of an enterprise application at your own home? We’ve all been there. You’re at home and you get the urge to check your voicemails or messages, but wait … I have to open the VPN application, type my password, wait … wait … wait … to connect. I won’t even mention those of you that 2-Factor. Now it’s time to open the application. Nevermind, I’ll just do it tomorrow.

In comes Cisco Expressway, Cisco’s solution for VPN-less Collaboration. Hosted on-site and under your control.

A few weeks ago a co-worker and I were tasked with getting it up and operational. In this article, I will show you the do’s and don’ts for a successful deployment, not to mention save you night after night of headache wondering where you went wrong. Lets Begin.

First, Design. Inititally, we looked at doing a 1 NIC design on the Edge server for simplicity. Simple was far from the truth. Cisco will tell you both designs are possible, but did mention that having one NIC was an administrative nightmare for your in-house firewall guy. With that, I recommend using 2 NICs on your Edge server that sits out in the DMZ. One of the NICs will be used solely for 1:1 NAT translation from a public to a private, the other for communication to the Core. NOTE: Both NICs must be given IP addresses in different VLANs. For this deployment, I assigned one NIC to a network behind the firewall (same network the core sits in) and one in the DMZ as mentioned above.

Next, Licensing. When you are ready to get started deploying the OVA files, remember that the Core and Edge use the same file. After deploying the OVA, you will be left with 2 identical VMs. From here, the license you apply will determine its role. This link will take you to a Cisco forum that is dedicated solely to applying expressway licenses. If that’s just not your thing, below is a quick license reference guide.

Moving on to Certificates. If you’re not like the 1% out there who deals with generating CSRs, issuing certificates, and troubleshooting TLS madness on a daily basis, right now would be a great time to take a breather and get some coffee. If you are, Congratulations! This next step will be easy.

In the authentication process, a TLS/SSL client sends a message to a TLS/SSL server. The server responds with the information that the server needs to authenticate itself. The client and server perform an additional exchange of keys. Before all this happens, the server must have a certificate on box that was generated with a CSR. A CSR is a certificate signing request used to generate a certificate for validation. In our case of the Expressway, there is a handy Generate CSR button under Maintenance>Security certificates>Server certificate. During this process, you will need to put in the CN (Common Name) field the FQDN of the server that is generating the CSR. If you are using this in an environment that has multiple domains, both external and internal, make sure to list them in the SAN (Subject Alternative Name) field. Failing to do so will result in a client that is logging in with a different domain than the FQDN of the Edge server not being able to connect.

Example: The hostname of Expressway-Edge is expressway.themulticast.com. If you are trying to log in with samantha@testsite.com you will not be able to establish a connection over TLS. Even though you own this domain and the internal zone exists, testsite.com does not exist in the SAN.

After creation, you will have the ability to download the CSR file. From here, this file will need to make its way to a Public Certificate Authority. Most CAs are quick and will have your certificate back to you in a few hours. At this point, you should now have 2 certificates. One for each server.  In addition to these certificates, you will need to grab your Public CAs root certificate to put on each box. This identifies the Root Certificate Authority and ensures the validity of your signed certificate from them. At this point, each VM should have the certificate from the other. Edge should have the certificate generated for the Core, Core should have the certificate generated for the Edge.

Finally, time for DNS and Domains. The main reason this solution works and works well, is the magical world of DNS. Below is a chart I borrowed from the Cisco DNS Jabber Configuration Guide. The Jabber client is hardcoded out of the box to look and see if the user’s login is registered as a WebEx user. If not, it moves on down the list, eventually making its way to your Expressway server.

Quite possibly the most important piece in all of this is getting the SRV records right. The public (external) DNS must be configured with _collab-edge._tls. SRV records so that endpoints can discover the Expressway-Edge to use for mobile and remote access. Below is a table for reference on what DNS changes need to be made.

In keeping in line with the table above, it’s worth noting that the Core must use Internal DNS servers and the Edge use Public DNS servers. The thought behind this is that the SRV records cisco-uds and _cuplogin are NOT resolvable outside of the internal network, otherwise the Jabber client will not start mobile and remote access negotiation via the Expressway. Not good.

To close out, I’d like to leave you with one last tip. You have gone through DNS, certificates, design, licensing, and checking logs, but you still have issues … check Configuration>Domains on the Core. You might think thats an obvious move as its listed in the Deployment Guide, but not so fast. If you use an ad-hoc made up internal domain for your internal zone you will need to list that domain here. All the configurations, troubleshooting and DNS SRV records will be useless without this small step. I really really hope this guide is beneficial to all of you folks venturing out in the world of Mobile and Remote Access without VPN! In Part 2, I will be covering a step-by-step configuration guide for this particular deployment. Stay tuned! Feel free to drop a comment below.

UPDATE: Part 2 is here!