Meraki

PaulMcG · ‎Mar 4 2022

Could it be some kind of virtual MAC address generated by the MX for it's own routing purposes? I looked at 2 different client MXs and every VPN client connected had some kind of 03: MAC address.

PaulMcG · ‎Mar 3 2022

If there is no MESH needed for outdoor, we run 7-17 for both 2.4 and 5GHz. If there are MESH APs, we run 10-21 on 5GHz and only broadcast client SSIDs on 2.4.

PaulMcG · ‎Mar 1 2022

For indoor profiles we run 7-14 on 2.4GHz and 10-17 for 5GHz. I see you have a few APs running MESH, those could justify running higher power on 5GHz to improve throughput. Outdoor profiles depend on the use case and whether or not MESH is required.

PaulMcG · ‎Feb 28 2022

Could be something on the WAN switch blocking the VIP like an access list. You could do a capture on the ISP side of the WAN switch to see if the ping goes out to the ISP. On the ISP side, if your VIP is part of the /29 attributed to you, I don't see any reason for them to be blocking the VIP.

PaulMcG · ‎Feb 24 2022

Pings to 8.8.8.8 should also work from the virtual IP source. Might have something upstream from the MX interfering?

PaulMcG · ‎Jan 12 2022

Are there any Layer 3 firewall rules on either MX that might be blocking the subnet?

PaulMcG · ‎Jan 12 2022

I just noticed in the image of routing from your first post you have a route for 10.69.10.0/24 but none for 10.69.11.0/24. Is your VPN configured to be full or split tunnel?

PaulMcG · ‎Jan 12 2022

Have you enabled Client VPN subnet in the site-to-site VPN settings?

PaulMcG · ‎Jan 11 2022

The datasheets for MR42 are still available online but they don't include the converage patterns for bluetooth, only wifi.

PaulMcG · ‎Jan 10 2022

Going from one template to the other is simply unbinding the network from template 1 and then binding it to template 2. This can be done under Organization->Configuration templates and selecting the template to unbind and then bind. The actual changing of templates is pretty straightforward, but how seemless this will be for end users depends on how each template is configured, as well as the network upstream of the APs. If everything is in place, vlans, DHCP servers, etc. it should be pretty smooth. This can all be looked at and planned ahead of time to minimize any impact during the actual switchover.

PaulMcG · ‎Dec 31 2021

Options for redudancy for non-Meraki VPN is limited. For point 1, you need to use the VIP, doesn't seem to be much in the documentation on the subject but the VPN might not even come up if a VIP is configured but you use the WAN IP of the primary MX. Point 2, I don't think this is possible, but I could be wrong. Point 3, dual WANs only work for VPN resilience in an auto VPN setup. Does nothing in a non-Meraki VPN situation. The only way to get the best resilience in a DC with Meraki is with either a vMX or physical MX(HA) setup at the DC.

PaulMcG · ‎Dec 30 2021

Yeah like you said sounds like a combination of things. I've seen some ISP modems have the sticky MAC problem as well. Any time I have an install with an ISP I know that can be an issue I reboot the modem at the same time I have the MX connected. You could make rebooting the ISP modem part of the setup process for a few sites and see if that solves the problem. But taping a paperclip to the box is a good backup.

PaulMcG · ‎Dec 30 2021

If the devices come online and giving a DNS error, just give it time and the warning will go away. If you really it gone sooner, you could send a reboot command, but if the device shows as connected but with an error, it's still functionnal, the error is more informative than anything.

PaulMcG · ‎Dec 30 2021

That's kind of an odd behavior, I've done the same thing with MX devices with DHCP for the WAN port and moved from site to site with no issues. Depending on the model of MX you are using, you could always use WAN2 in your office and then WAN1 when on site. But it shouldn't behave in the way you describe.

PaulMcG · ‎Dec 29 2021

There's no control over DHCP for VPN clients, but you can specify what DNS server is given to the clients from the "Client VPN" configuration page. Don't know if that will fix the issue you're having though.

PaulMcG · ‎Dec 22 2021

Topology rarely comes out from left to right as you have it depicted in your diagram. Would be nice if it did. The reason sw1 shows up on the left might have to do with it being the lowest STP bridge priority, but other than that, there really isn't anything you can do to change how the topology comes out on dashboard.

PaulMcG · ‎Dec 21 2021

The alert only is only to advise that the port is down for the time indicated. There's nothing done automatically to determine why it's down, only that it is down. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications

PaulMcG · ‎Nov 5 2021

While connected to client VPN, are you able to ping the RDP server address, or any other address on the LAN?

PaulMcG · ‎Nov 5 2021

Check layer3 rules in the firewall menu. You might have rules restricting the subnet for the RDP server from reaching the client VPN subnet.

PaulMcG · ‎Nov 3 2021

This is the dashboard telling you that your local subnets overlap with a configured static route. Even if you created a vlan with a 192.168.x.x subnet, you will still get the same message as your 10.0.0.0/16 as well as client VPN subnets are the reason for the message. Also, creating a vlan with a /16 mask is unnecessarily large, with over 65,000 possible host adresses. Most of the time vlans are created with a /24 mask, giving you 254 possible host adresses, as well as less chances of overlaps.

PaulMcG · ‎Oct 27 2021

I've got a few clients running Z3 at home and always behind some kind of router, usually one supplied by the ISP, and haven't seen this behavior. Not sure what could be causing it. When you say her service interrupted, do you mean the VPN cuts out or the Z3 has no internet access whatsover? Your idea of putting a switch after the modem to give internet access to both the Netgear and Z3 would only work if your ISP gives out more than one public IP, which it probably doesn't.

PaulMcG · ‎Oct 27 2021

I don't know that there's any easy way of copying a network when it comes to this situation, but one trick is to add a new vlan with the new addressing for the site but with a different vlan ID. Once that's done you can erase any DHCP settings from the unwanted vlan, allowing you to erase that vlan and then just change the vlan ID of the new vlan you created. That allows you to avoid having to remove any firewall rules that have a class A/B/C source IP. It's still a pain to do but if you have a lot of firewall rules, it's still easier. It's still faster than starting the network completely from scratch and avoids mismatches between networks. Another thing to check for that won't generate any errors are traffic shapping rules. If a rule matches a local subnet, VOIP for instance, and you change the addressing of that subnet for a new site, no error message pops up to say your traffic shapping rule applies to an non-existing subnet.

PaulMcG · ‎Oct 25 2021

It can be done but the tester has to be made for it. I've used an EXFO OTRD that had the ability, but there was a seperate port for testing a live fiber and a dark fiber. There was a warning that using the port for dark fiber on a live one could cause damage.

PaulMcG · ‎Oct 25 2021

I've only deployed captive portal on MR (not Ucopia) so can't say how it would work on an MX, but this is the Meraki documenation for both devices. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Splash_Page#Splash_Page_Customization

PaulMcG · ‎Oct 21 2021

Option located under Wireless/access control. You need a RADIUS server to make it work. But doc mentions a workaround using a splashpage. https://documentation.meraki.com/MR/Encryption_and_Authentication/Enabling_MAC_based_access_control_on_an_SSID

About PaulMcG

PaulMcG

Community Record

Badges