Securing Your Connection Anywhere You Go

We all know that there are a lot of incomplete security models. Firesheep made this fact painfully obvious to those who regularly work from public hotspots. Although this issue extends beyond insecure wireless deployments, unencrypted hotspots are an easy target. When network traffic isn’t secured in the application layers AND that same traffic is not secured in the network or datalink layers, bad things can and do happen.

TLDR–This article solves this problem by utilizing a Meraki MX60 and the VPN client Native on OSX. To skip to the good stuff, click here.

One approach that some people decide to employ is utilizing a VPN connection for their Internet traffic when connected to untrusted networks. For years, enterprises have utilized these controls to allow secure access to corporate resources. A common trend to day includes utilizing “the cloud” for sensitive enterprise and personal data. While these systems *should* be appropriate resilient, we know that is not always the case. In addition to that, federated authentication schemes and password reuse can also pose additional risk to broken systems and less security conscious users.

Having easy access to some gear, I have been using a Meraki MX60 for a few months. This device makes the configuration simple for several reasons.

  1. Being a cloud managed platform, public IP changes are always tracked and available
  2. DNS “A” records have a configurable hostname and are maintained by the cloud management platform
  3. Standard Protocols are used and work natively with a wide variety of operating systems

Meraki Configuration

  1. Navigate to the Meraki website and choose Login. After entering your credentials, you should have access to the Dashboard.
  2. When in the Dashboard, select the network containing the MX device.
  3. In the left column, choose Security Appliance, then Addressing & VLANs on the fly-out menu.
  4. Scroll down to Dynamic DNS.
  5. Enter a hostname and record the fully qualified DNS name for the current primary uplink. This will be used in the client configuration.DDNS Settings
  6. Save the changes.
  7. In the left column select Security Appliance again, then Client VPN
  8. Change Client VPN Server to EnabledMeraki Client VPN
  9. Set a Client VPN subnet in the form of 192.168.10.0/24. This can be any unused RFC1918 address range
  10. Configure an appropriate pre-shared key (aka Secret).
  11. Leave the Authentication set to Meraki Cloud if you wish to use credentials configured in the Meraki Dashboard
  12. When using the Meraki cloud for Authentication, the users are configured at the bottom of the page. It is important to make sure each vpn user is Authorized for Client VPNMeraki VPN User

 

 

Client Configuration

At this point, it is time to configure a client and test from an outside network. Using the native Mac OSX client, the configuration is performed from System Preferences, Network.MAC VPN Settings

  1. Choose the + at the bottom of the page to add a new connection. When prompted for Interface select VPN, VPN Type L2TP over IPSec, and provide any unique Service Name.
  2. Highlight the newly created connection on the left and provide additional configuration parameters on the right.
  3. For the Server Address, provide the FQDN from Meraki step 5 above.
  4. Select Authentication Settings and configure the Shared Secret to match the Pre-Shared Key from Meraki step 10 above.
  5. Apply the Settings.
  6. Click the Advanced button and check Send all traffic over the VPN connection (this is similar to Send All Traffic To Default Gateway in Windows)
  7. Choose OK to exit the submenu
  8. Optionally, choose whether or not Show VPN status in menu bar (I prefer this to make it easily available)
  9. Connect and enter the credentials when prompted.
  10. To test, go to a website like IPChicken and confirm this is the outside address of your MX60 and not an IP Address from your hotel, MiFi, or public hotspot provider.

Benefits of this Configuration

  1. Provide an underlying encrypted architecture that you control
  2. Allow your trusted/known/home IP address to be used regardless of geographic location

Conclusion

As with anything, this configuration should be evaluated and assessed on a per use case basis. The thing I particularly like about this is that it is a simple way to solve a lot of my concerns around using public WiFi.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.