In today's blog post - we'll be checking out how to integrate a Meraki MX firewall to Cisco's Umbrella Secure Internet Gateway (SIG) & Secure Web Gateway (SWG) services.
Interested in seeing how to do this with Cisco Viptela SD-WAN? Check out this post
Note: This integration is still rather new - so I anticipate some of the screenshots & steps below may differ as this post ages.
What are SIG & SWG?
Good question! A lot of us are probably familiar with Cisco Umbrella (formerly OpenDNS) for the DNS-layer security products. Using Cisco Umbrella, we can configure our end PCs or DNS forwarders to use the Cisco DNS servers. Then, we apply security policies to allow/deny DNS queries based on our policy.
Now applying security policy at the DNS level is great! Typical web filtering only inspects HTTP/HTTPS traffic, but inspecting DNS traffic allows us to stop threats that might not use those typical ports. While there may be some applications or malware that use hard-coded IP addresses, a good majority use a domain name that requires a DNS lookup.
But what if we wanted to still do web filtering too? Or maybe we want a centralized, cloud-hosted firewall service? That's where Umbrella SIG & SWG come in.
Secure Web Gateway (SWG) is pretty much exactly what it sounds like. It's a cloud-hosted web filter or web proxy, where we can set URL-based policys to permit or deny access. It supports the usual allow-lists, deny-lists, HTTPS inspection, file inspection, and policies based on user/group identities.
Secure Internet Gateway (SIG) is a large, cloud-hosted firewall service. What we can do with SIG is tunnel all of our traffic to one centrallized location to apply firewall policies (permit/deny/etc).
Why would we want either of these functions to be cloud-hosted? Well we might not have the resources at every remote site to perform firewalling & web filtering - or we don't want to invest in beefy hardware in our corporate datacenter, and backhaul all of our remote traffic back for inspection. The cloud-hosted piece also means a central management point, so only one place to make change for all of our remote sites - rather than having to touch dozens or hundreds of remote devices.....Did someone say SASE? 🙃
With all that said - Let's get into making this work!
Note: There are many ways to use Umbrella SIG/SWG (IPSec tunnel, PAC file, Anyconnect, etc). This particular post will only cover IPSec via Meraki MX.
Step 1: Getting our Keys
First thing we'll need to do is on the Umbrella side. We'll need to generate tunnel keys for our Meraki MX to use for IPSec negotiation.
We'll log into our Umbrella dashboard at https://login.umbrella.com/
Once we're in, we'll navigate to Deployments > Core Identities > Network Tunnels. Shown below, we currently have no tunnels configured:
In the upper right corner, let's click the Add Tunnel button.
We'll now see the following screen to begin creating our IPSec tunnel:
Here, we'll need to specify a name for our tunnel & which device type. The name can be anything we choose that helps us identify what locations are using this tunnel. I've specified MX64 as my tunnel name, since I only have one MX that I'll be testing this with. We also have Meraki MX as an option in the Device Type drop down - so we'll select that as well. Then, we'll click Next.
Then we'll need to configure our Tunnel ID and Passphrase:
The Tunnel ID we'll be sending later, as part of our IPSec local ID. The passphrase will be used as our pre-shared key for the tunnel config. Once we're done with that, click Save.
As long as our ID & passphrase are all good, we'll be presented with a box to easily copy these parameters into the Meraki config:
Finally, we'll be dropped back to our Network Tunnels page - where we can see that our tunnel is configured, but not yet established. Let's fix that & hop over to the Meraki dashboard!
Step 2: Meraki MX IPSec Configuration
Okay, now onto the fun stuff.
We'll log into our Meraki Dashboard at https://account.meraki.com/secure/login/dashboard_login
Once we're in, you'll need to select the network with the MX you want to connect. For me, I currently only have a single network, which contains my MX firewall.
Then we'll navigate to Security & SD-WAN > Configure > Site-to-site VPN.
Assuming we have no other VPNs configured, you'll have to change the VPN Type to Hub (Mesh) or Spoke. In my case, Umbrella SIG will be the only VPN I'll have configured - so I'll go ahead and use Hub (Mesh). Don't mind the error regarding exit hubs, as we'll be configuring a non-Meraki peer below.
Okay, scrolling down the page just a bit - we'll need to specify which VLANs/internal subnets will be routed across the VPN & pushed through Umbrella for SIG/SWG:
For testing purposes, I have a VM in a subnet labeled DMZ that I'll be using - So that will be the only VLAN that I'll set to VPN On.
Next we'll take a look at configuring Non-Meraki VPN Peers.
As shown in the screenshot below, we'll need to configure the following settings:
- Name - This is locally significant, I set mine to Umbrella_SIG
- IKE Version - Set this to IKEv2
- IPSec Policies - Custom - See below
- Public IP - This is the peer Umbrella Datacenter
- Choose the DC closest to you here
- For this post, I'm using the New York DC
- Local ID - Set this to the Tunnel ID we got from Umbrella
- Remote ID - Leave blank
- Private Subnets - This is what destination IPs will be routed over the tunnel
- Since this is intended as an Internet gateway, we'll use 0.0.0.0/0
- Preshared Secret - Set this to the passphrase we configured in Umbrella
- Availability - Set this to which networks this tunnel should apply
- Since I only have 1 network & 1 MX, I set this to All Networks
Okay - I mentioned above we'll need to set some custom IPSec parameters. Here's what we'll configure as a custom policy:
Note: Turns out in the drop down menu, there is also an option for "Umbrella", so you don't have to create a custom policy. That being said, the Umbrella preset uses DH group 5, but Umbrella's docs ask for DH group 14.
Lastly, we'll be able to configure whether or not we want firewall logging (I enabled this) and also whether we want to add access-lists to permit/deny any traffic over the VPN. For now I'll be leaving this as permit any.
Finally - we can click Save to push our configuration to the MX appliance!
Step 3: Validation & Testing
Hopefully once we get all that configuration done, we'll be able to see our tunnel come up.
We can validate from both sides, but let's start with Meraki. In the Dashboard menu, we'll navigate to Security & SD-WAN > Monitor > VPN Status.
Then we'll need to click the tab for Non-Meraki peer:
With any luck, we should see the little green circle showing that our tunnel is online.
If your tunnel doesn't come up immediately, you may have to generate some traffic from your VPN subnet to the internet. This will force the MX to try and connect to Umbrella.
It's also worth noting - sometimes it may take the Meraki dashboard to show a successful connection. A better indicator is by checking the Umbrella dashboard, or checking manually with a device you are expecting to route over the VPN.
If for any reason we have trouble, we can also check our VPN negotiation logs by going to Network-Wide > Monitor > Event Log.
On this screen, make sure you've selected for security appliances at the top. If needed, we can also filter events by All Non-Meraki VPN / Client VPN.
Since my tunnel came up with no issues, the output above shows a successful tunnel negotiation.
Let's jump over to the Umbrella side, and see what the Umbrella dashboard shows.
Back on the Network Tunnels page - we should see that our tunnel now shows as Active.
This screen will also so the public IP that our MX is using to connect, as well as which Umbrella datacenter we've connected to.
Okay! That's it for now. To try and keep this blog post from getting too long, I've decided to split this into two parts.
If you're interested in seeing how to configure Umbrella's cloud firewall & web filtering policies - please check out my YouTube Video above!