Ran into an interesting issue today related to a Meraki MX deployment for a large multi site customer.
Normally in a Microsoft built network, you want all your clients and servers to use the Microsoft DNS infrastructure. Let us be clear, it does make things a little easier when Microsoft machines just know about each other.
I ran into a problem where the Meraki MX block page was not showing when users attempted to use regular HTTP web sites. On HTTPS sites, no block page is shown, that is by design, however non SSL sites should see a block screen.
A little background.. When you try to visit a page that is blocked by Content Filtering with Meraki – you will be greeted with a screen like this..
How do we get this page to display? The Meraki MX intercepts the session and sends a HTTP 302 Moved Temporarily message to the browser and redirects the browser to a URL like this.
If you resolve wired.meraki.com on the internet it resolves to an IP of 220.127.116.11
Locally the DNS for wired.meraki.com will resolve to your Meraki MX — that is if you were using your Meraki MX as your DNS. In large Microsoft deployments that DNS server might use root hints or forward lookups somewhere else on the network, so the response would be 18.104.22.168.
Why is this a problem? If you look at the URL, you will notice that it opens port 8090, a quick check of the internet IP 22.214.171.124 will show that port 8090 is not open on that IP, so if the client resolves wired.meraki.com and does not get an IP of an MX SOMEWHERE on the network — your client is greeted with
So how do we fix this? You have two options
1) Make all your clients use a Meraki MX, or a DNS server that always sends forward lookups through a Meraki MX device (Good luck, the Microsoft Server team is probably not going to want you to change your client DNS settings)
2) Add a host file entry to the workstation (No!)
3) Add wired.meraki.com to your Microsoft DNS.
So going with option 3, if your Microsoft DNS add a forward looking zone called “wired.meraki.com” and then create an entry pointing towards your MX, like this.
1) Create a forward lookup zone called “wired.meraki.com” — NOT MERAKI.COM if you do this you will prevent your devices from contacting the Meraki Cloud Controller.
2) Create a Host (A) record like this – nothing under the name, as we want the wired.meraki.com domain to respond, replace the IP address with the IP of your MX.
If you have multiple Meraki MX devices create multiple entries in your DNS, the machines will always choose the device within their local subnet first, if for some reason they do not – it does not matter as the other devices will technically respond, but we do not want those responses from over the WAN.
Hopefully someone else runs into this problem and this can be of assistance.
4 thoughts on “Meraki MX, The Block Page, and DNS.”
[…] conversations, I thought it was time to stir the wireless pot a little. First was my retweet of an excellent DNS workaround post from Justin Cohen (@CanTechIt). One of the responses I got from wireless luminary Andrew von Nagy […]
Excellent. I have been working with support on this, and they didn’t know. I’m glad you posted. I’m trying now
THANK YOU! This JUST came up for http://www.hbogo.com internally (for whatever reason) and only users that were part of the domain would be affected. Guest/home computers plugging into the LAN wouldn’t exhibit the issue so it was baffling me, esp. when we didn’t purchase the Meraki Security License so Content Filtering isn’t even an option in the MX.
I work for a VAR and in the last 2 weeks found two customers with this issue. It was determined that the FW isn’t responding to DNS requests from the DC out to the public DNS server. We did verify that the requests for wred… insn’t traversing the FW and making it to the internet becuase there is no responce from the intentet in our captures. So the FW is block the outbound request but not responding either.
We escalated with engineering and they identified that there were some known “issues” with the DNS responces and that they have a fix in some beta firmware. We loaded that beta and it resolved the issue.
Ask for the beta as of the time of this writing.