Meraki

KarstenI · ‎Sep 23 2020

@redsector wrote: But what I see is that both MXes are spaking with that WAN IP address. Yes, both have a connection to the dashboard. It is completely different compared to for example an ASA where you can configure it with only one usable public IP.

KarstenI · ‎Sep 23 2020

This is not how MX HA works. Both units need individual connections to the internet, you can not share one IP on both appliances. Two/three solutions come to mind: 1) use a separate IP for the second MX 2) Use a different ISP on the spare MX, that could be e simple LTE-router just for dashboard connectivity, and in case of primary MX failure, you connect the primary ISP to the second MX 3) Use the second MX as a cold spare

KarstenI · ‎Sep 22 2020

As a test, can you change the printer from plain SMTP to SUBMISSION (tcp/587 with username/password)?

KarstenI · ‎Sep 22 2020

Does that mean you are using the roaming-client or the AnyConnect roaming module on the PCs? Are the wireless and wired clients using the same policy and Domain-config? Also, go to Activity search in the Umbrella Dashboard and search for your internal Domain name. If it shows up, the domain-management is configured incorrectly.

KarstenI · ‎Sep 22 2020

Did you change your Umbrella-Setup recently? And who sends the DNS-requests to Umbrella? The client, the MX, a VA? I would first look at the Umbrella dashboard and/or the MX-Umbrella-config if your domain names (the domains that should be processed by your DNS) are configured correctly.

KarstenI · ‎Sep 21 2020

- Do the WLAN clients receive the right DNS-server? - Is it only DNS and the rest is working as expected? If nothing works, Did you perhaps forgot to allow the WLAN clients access to local LAN under Wireless -> Firewall?

KarstenI · ‎Sep 18 2020

Yes, that was a faulty assumption. Content-filtering is not done when the traffic reaches the MX over the VPN-Tunnel. Best solution (IMO): Deploy Cisco Umbrella to the branches and configure Content-filtering there.

KarstenI · ‎Sep 18 2020

I don't think that you can get a good answer here as there is nothing like a backup in the Dashboard. If you want to achieve something a backup is for, like your mentioned getting back to operation after a disaster, there is only one way: Generate a script that builds all your networks via API and document exactly where manual adjustment is needed if the API can't do it.

KarstenI · ‎Sep 18 2020

Can you explain what you mean with "and I need to be on this VLAN also"? If your DHCP-server is in VLAN 1 and the client is in VLAN X, then DHCP-relay is the feature to use. If your client is in the same VLAN as the DHCP-server, no DHCP-functionality is needed on the L3 device (the MX) between them as the DHCP-server can directly give the client its config.

KarstenI · ‎Sep 18 2020

@Cain wrote: Indeed this is my current work around. I have a webhook that fires off a Python script that modifies the layer 7 rules when the WAN link changes. Do you have a blog? Would be worth publishing your solution.

KarstenI · ‎Sep 18 2020

I also have no easy solution and having separate rules per WAN-interface would be really great for this use-case. But how are your Python skills? Based on the availability of the primary link, you could change the L7 firewall rules with the Dashboard-API.

KarstenI · ‎Sep 17 2020

If you have some dollars of the budget left, look at Cisco Umbrella. In my experience, the Blocking of inappropriate content is more powerful than the MX-built-in content filter.

KarstenI · ‎Sep 16 2020

All in all, that should work. If you have a spare public IP, I would put the MX in parallel to the ASA and migrate the branches. This way you don't have to change the MX when done and you can also directly use the security-features of the MX for your outgoing traffic.

KarstenI · ‎Sep 15 2020

Never used them myself, but have heard good things about http://www.acceltex.com/skins/

KarstenI · ‎Sep 10 2020

Sounds good, I would also expect that it will work. When adding the route to the router/firewall, make sure that this device is able to "hairpin" the traffic. For example, a Cisco ASA would not do that without dirty config.

KarstenI · ‎Sep 9 2020

The approach of configuring a 192.168.0.0 network on Site B can not work. That would be L2 bridging which is not available on the MX and in most cases not a good solution. There should be no difference in the VPN connectivity of dual-armed vs. one-armed. Is it only the VPN-connection that is failing or also the connection to the VPN registry? Have you done any changes at the site1 MX? Is there any config for the 192.168.10.0 in MX1? That could be a problem.

KarstenI · ‎Sep 9 2020

First, this should work and it is pretty much what I am running in my office (MX in routed mode) and home-office (Z3 in concentrator mode in a DMZ of a Firepower Appliance). If it does not work I would first look at the internet-connection of the spoke-MX. Is the access-control and NAT ready to support the MX? But I would also evaluate if you can replace the current firewall with the MX or add the MX to the given setup in routed mode with a direct connection to the internet. That could make everything a little easier.

KarstenI · ‎Sep 8 2020

But if two systems are synchronized or one replicates to the other, then we can not call this a backup. If the dashboard config gets screwed up, the switch will be screwed up seconds later automatically.

KarstenI · ‎Sep 5 2020

Ok, there is more than the splash-page. Make sure that a single user can not saturate your internet-link. Could be done by a per-client bandwidth limit. Make sure that bulk traffic like online-backup is shaped to a reasonable amount. Filter traffic to the internet that can be harmful to others. I generally do not allow guests tcp/25 and snmp. Also think about L7 filters for things like P2P applications. Configure Layer 2 LAN isolation so that one guest can not attack another. This is automatically done if you use Meraki DHCP.

KarstenI · ‎Sep 5 2020

I do not think that there are general best practices. But there are different goals that a hotel could have. Some want to make money with the WLAN, some want to provide best guest experience. As a traveler, I of course prefer the second goal. If your local rights allow this, I would go for the "click through" splash page. The guest has to accept an "acceptable use policy" and is connected to the internet. That is very convenient for the guest.

KarstenI · ‎Sep 5 2020

As always: "it depends". Best you go through all the possibilities that you have with Meraki-Splash-pages and pick the one that fits your need. Here are some documents to start: https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Splash_Page https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Customizing_the_Splash_Page https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Details_for_Meraki_MR

KarstenI · ‎Sep 3 2020

I am not sure if I get you right, but have you looked at the Organization Summary Report? There you can: Restrict to a time range select a network select an SSID And there you see the Clients per day:

KarstenI · ‎Sep 2 2020

> Anyone can justify why Meraki sells transceivers that cost 40X compare to a 3rd party compatible units? I would say "easy money" ... We had an "only Cisco" customer that refused to save some bucks on third party optics because he wanted the "official" ones. And what I heard, that was not the only one.

KarstenI · ‎Sep 2 2020

I have a broad range of 10GTEK modules running in MS-switches and they are working fine for a couple of years. A colleague had one SFP+ that did not work, but well, that's how it is sometimes.

KarstenI · ‎Aug 21 2019

About thirty people celebrating in the picture and only one small cake ... I think these are very sad times at Meraki HQ ... 😉 Nevertheless, happy birthday!

About KarstenI

KarstenI

Karsten Iwen

Community Record

Badges