A little while back, I posted this on Reddit about setting up a Ubiquity Unifi Security Gateway (USG) or Edge Router Lite (ERL) to selectively route packets through a VPN interface; I wanted to elaborate a bit on the setup for this.

The goal

The goal was have my Unifi device establish two networks, one that behaves normally and another that routes all traffic through a VPN interface automatically. The value prop for a setup like this is that you can avoid having to configure each device & the VPN on each separately; simply connect to the network and that's it. It's simple, uses a single VPN connection for multiple devices and even lets friends & family use it easily with zero configuration.

In my case, I setup a second SSID and tied to different subnet (tagged VLAN) so simply by switching networks, you could gain VPN protection. Normally, this is very difficult to do because the router has a single default route; all packets not destined for local networks will exit using said default route.

This technique is made possible through the use of policy-based routing, which establishes multiple routing tables and rules on when to use a given table. This permits the router to determine the next-hop based on the source address, not the destination address.

As long as the Ubiquity router is the default gateway (it should be if it's serving DHCP), machines on network 192.168.20.0/24 will now automatically route packets through the USG and then the USG will pick the vtun0 interface as its next-hop for those packets. Packets from other sources (e.g. your regular LAN) are routed normally through the WAN link.

Note that you can also set the next-hop to a host, by using this static route instead of the one above (note removal of the blackhole - you'll need to do that on the host specified in next-hop to avoid privacy leaks):

This is useful if you have a home server connected to VPN, and want to route packets through its VPN connection instead of the USG (some additional setup required; more on that in a future post).

Troubleshooting

If this setup does not work as expected, the easiest way to troubleshoot is to verify connectivity. tcpdump will be your best friend here. Something like tcpdump -i interface -A port 80 will trace all HTTP traffic on the interface supplied, and

You'll want to verify connectivity in this order:

1. Verify source packets leave a host

Use any machine on the 192.168.20.0/24 network to test and start generating some traffic, ensuring the packets do hit the network. You can use something simple like curl google.com to trigger some traffic, and monitor the network interface with tcpdump per above to make sure the packets are sent out.

2. Verify packets are reaching your next-hop

Your next-hop is probably the USG/ERL router, but could also be an IP on your network as well. Now that we've confirmed packets are leaving, make sure they are arriving by inspecting the LAN-side interface on your configured next-hop.

Connect over SSH to the next hop (if it's a USG/ERL read this) and run sudo -i. Use ip a to list all interfaces & configured IPs; this should let you pick out the interface name associated to an IP on the 192.168.20.0/24 network.

Now run tcpdump against that interface and then generate some traffic on the test host from step 1. Do you see them arriving?

3. Verify packets are exiting your next-hop on the VPN interface

If you've made it this far packets arrive on your next-hop so let's make sure it's forwarding out through the right interface. First, list all configured policy-based routing rules with ip rule - you should expect to see 0 (default table) and 1 (for certain marked packets). List out each routing table using ip rule show table X to make sure things look as you'd expect. For example, ip route show table 1:

default dev vtun0 scope link
blackhole default metric 100

Or if you configured next-hop as a host instead:

default via 192.168.20.100 dev eth1.11

Now run tcpdump on the shown interface and verify if packets are existing as expected.

Note for Unifi users

Lastly, note that if you use a USG instead of a ERL, these settings will not be persisted. Your settings will be overwritten by Unifi Controller after any provision or reboot operation -- you will need to manually persist them by exporting to a config.gateway.json file.

I just picked up some new networking gear, so this will be the first of a multi-part blog post about my learnings configuring Unifi gear.

One issue I noticed right away was that it is not possible, via CLI nor GUI, to configure fixed IP address for a host that relies on more than 1 of the configured networks/VLANs. Since I have a home server (user VLAN) that is also hosting the controller softare (management VLAN) and also acts as a gateway for sending packets over its VPN interface (VPN VLAN), this was necessary for me.

It is possible but requires a bit of manual configuration using a config.gateway.json file. First, if you have configured a fixed IP for the host, unset it.

Building the Event Hub connection string

You can view your IoT Hub's Event Hub-compatible by opening your IoT Hub resource in the Azure portal and navigating to the Endpoints blade, then clicking the Events (messages/events) endpoint. You will find the Event Hub-compatible name, and Event Hub-compatible endpoint (in the format of sb://iothub-ns-foo.servicebus.windows.net/) - keep note of these for later.

Next, navigate to the IoT hub's Shared Access Policies blade. You will need to either use one of the existing policies or add your own, and the policy you choose must have the Service connect permission. Click any policy to view its associated primary key.

Now, we can use these four pieces of information to construct an Event Hub connection string, which follows the format Endpoint=sb://EH_COMPATIBLE_ENDPOINT;EntityPath=EH_COMPATIBLE_NAME;SharedAccessKeyNa‌​me=IOTHUB_POLICY_NAME;Share‌​dAccessKey=IOTHUB_POLICY_KEY.

Configuring Azure Functions

We will now setup an Azure Function with a trigger using the Event Hub-compatible information.

Open the Azure Function resource and switch to the Integrate tab. Add a new trigger and choose Event Hub, which will reveal the following settings page:

Enter the Event Hub-compatible name collected from IoT Hub earlier under Event Hub name and then press new to enter the Event Hub connection string derived earlier.

Lastly, we need to add code under the Develop tab with a parameter that matches the Event parameter name field, so use the following:

Testing the connection

Under the Function's Develop tab, click the Logs button from the toolbar to open the execution log. Next, send a cloud-to-device message -- if you haven't setup a device, simple_sample_device.js from the IoT Hub Node.js SDK does nicely.

After sending your message, you should see that your Function triggered successfully.

What about in ARM templates?

This manual setup is fine for testing, but what about automation for when moving to production?

ARM templates provide a reference() function that resolves a resource's runtime state. It's perfect for obtaining the Event Hub-compatible name that was provisioned as it was created:

The Skype for Business App SDK and Skype Web SDK are great ways to build the unified communication experience provided by the Skype for Business (previously Lync) server directly into web and mobile applications and deliver new interactive and collaborative experiences into your application.

If you're getting started with the Skype SDKs and/or Office 365 for the first time, the documentation available on the The Skype Developer Platform is a great place to start, but there are a number of steps you'll need to work through before coding.

In this post, I'll detail how to get setup with Skype for Business Online (Office 365) using a developer tenant and get coding as quickly as possible. As well, this is a good time to note that that at this time, some features of the SDKs are in preview. More features are coming out with every release!

Good to know: compatibility & platform features

As of writing (Jan. 2017), both the App SDK and Web SDK support connecting to on-premise and online (via Office 365) deployments.

However, at this time there are some important distinctions between the capabilities of the SDKs on the two platforms and in compatibility with O365 vs on-premise for meeting join. These differences will be rounded out in future SDK releases (for details on roadmap, see the Andrew Bybee's Ignite 2016 talk).

App SDK

The App SDK is available for iOS and Android apps, and supports the unauthenticated workflow. Meeting join, IM and audio-video communication is possible but done anonymously, using only a meeting link. There is no opportunity for a user to sign-in, so tasks like contact management are not available.

Web SDK

Contrary to the App SDK, the Web SDK has better support for authenticated workflows. Contact management, 1:1 conversations and more is available from the Web SDK after the user has authenticated. Anonymous meeting join, where the end-user joins a conference without signing in, is available but only when connecting to on-premise Skype for Business deployments at this time.

It's also important to note that both Chrome and Firefox have announced the deprecation of NPAPI plugins, which prevents the use of the Skype for Business Web App Plug-In. As such, audio-video functionality will be limited in Chrome and Firefox at this time.

IE11 and Safari both work with the web plug-in, and Edge supports A/V calling without any plugins via its built-in ORTC stack.

Setup an Office developer tenant

In order to get started, you'll need to be an administrator on Office 365 tenant and have 2-3 users that are licensed with Skype for Business. If you do not already have such an account, sign up at dev.office.com/devprogram to obtain a free Office developer account.

Once your account is activated, visit portal.office.com, click the Admin tile, then add 2-3 users and assign them a developer license.

App SDK

If you intent to build a mobile app, you are now ready to go - all you need is your app and a meeting link! Check out the meeting join samples for Android and iOS, and the App SDK documentation

You can generate a meeting link using the Skype for Business integration with Outlook, the desktop clients or the Lync Web Scheduler. To create them programtically, use the UCWA API. Meeting links follow the format https://meet.lync.com/tenant_name/organizer_username/meeting_id.

Web SDK

Because the Web SDK supports authenticated workflows, it requires some additional setup in order to authenticate users against Azure AD.

Creating an Azure AD Application

Registering an application will allow the Web SDK to perform OAuth authentication aginst users in an Azure AD directory. Previously, managing Azure AD applications required delving into the classic portal (instructions here) but fortunately Azure AD management is now available (in preview) in the new portal:

Choose a human-readable name for your application and a unique sign-on URL. If unsure, use something like https://tenantID.onmicrosoft.com/appname - you can change it later once you move to production. Leave the type as Web app / API.

Select the Manifest button to open the manifest editor:

Then set oauth2AllowImplicitFlow is set to true:

Next, navigate to the application's Properties blade and change Multi-tenanted to Yes. This will ensure that people outside of your Office tenant can use this application.

Navigate to the Reply URLs blade and enter the URLs at which your application will be hosted. Note that while developing your application, adding http://localhost is convinient but be aware that it means anyone who stands up their own site on http://localhost and knows your client ID can authenticate against your application. Tread carefully!

Navigate to the Required Permissions blade and add delegated permissions for Skype for Business Online:

I'm writing this quick post at the end of 2016 to wish everyone happy holidays and let you know about some changes coming in 2017.

Employment

Earlier this year, I stopped working for my company Diffingo Solutions Inc. and am excited to say that I now work at Microsoft, as can be seen on my github profile (@stewartadam). I think that the direction Microsoft has taken in the past two years has been very positive and I'm exicted to see what the future brings.

Of course, there's the mandatory note: the opinions on this blog are my own and may not represent those of my employer. However, given the technologies I interact with on a day-to-day basis, you may notice an increase in blog posts about technologies owned by my employer ;)

Comments are now disabled

As well, due to an influx of spam comments that are bypassing CAPTCHA and other automated anti-spam methods, I have disabled comments on my blog. I expect this will be the case for the forseeable future.

New blog style coming

I am likely going to convert my Drupal-based blog to one based on Markdown or other static rendering. Drupal has been great to me, but Markdown is so much easier to author in and requires 0 maintenance. As well, the rate at which I can author content has slowed so Drupal's original use case for me (maintaining Views-based lists of the various categories of howtos I was writing) no longer applies.