Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Zac123
Community Record
17
Posts
0
Kudos
1
Solution
Badges
Feb 8 2022
7:31 AM
Hey all: I just fixed an issue that I didn't find on this forum so I figured I would share what I found. I'm working on a deployment with a handful of sites using Meraki MX and MS appliances. The sites will use AutoVPN to connect to each other, but some of the sites lost their connectivity to the VPN Registry and the VPNs connecting those sites eventually stopped working. They were connected at some point, but it just stopped working. I read on this forum that some of the VPN Registries were overloaded and that support can add some registries. I called support and had them do that. It partially fixed the problem. This is a hub and spoke topology with two hubs. One site could connect to both VPN hubs, but the other site couldn't connect to one of the hubs. After the weekend, neither site could connect to either hub. Both sites could ping the registries they were using, and I could see one-way traffic to the registries in a packet capture. All the sites have a pair of MX appliances in warm spare/HA and have virtual IPs configured. Out of curiosity, I de-programmed the vip on one of the sites that couldn't connect. The spoke could then talk to the VPN registries and the VPNs came up. I put the vip back in and then connectivity was lost. With the virtual IPs configured, I tried turning off AutoVPN and turned it back on. After that, the site was able to connect to the registries and the VPNs came up. Initially, the dashboard didn't let me turn off AutoVPN because I had firewall rules, but I got around that by creating a disabled source-based route for all the networks on the device. I thought this was a strange problem because the issue went away if I removed the virtual IP. When the virtual IP was configured, the VPNs wouldn't work but pings sourced from the vip would reach the registries. It's like something wasn't right in the registry, but toggling AutoVPN got it working. I'll be watching the VPN status over the next few days. Hopefully it says working.
... View more
Labels:
- Labels:
-
Auto VPN
Feb 1 2022
7:21 AM
Thanks for your reply Manjinder. I read that in documentation and is why I thought it sits between 6 and 7.
... View more
Jan 31 2022
2:25 PM
Hi all: Here's the list of route priorities. Does anyone know where Source-based Default Routes fall? Directly Connected Client VPN Static Routes AutoVPN Routes Non-Meraki VPN Peers BGP learned Routes NAT* I'm guessing between 6 and 7, but I can't find a solid answer.
... View more
Jan 31 2022
1:57 PM
I have an update on the issue. We moved the devices (WAN and LAN ports) off the fabric extenders and on to the switches that the extenders connect to, and now the issue isn't happening anymore. I can reboot either MX without the connected switchport going in to errdisable state.
... View more
Jan 25 2022
6:58 AM
Thanks for the reply @Ryan_Miles. I do have some packet captures we took from the Nexus as I rebooted one of the MX appliances. I attached it to my Meraki support ticket if you want to take a look. There are BPDUs in there, but I'm pretty sure those aren't from either MX and now I'm wondering about your last thought. Maybe traffic is bridged for a moment as the MX is going down for a reboot. BPDU Guard is triggered a few seconds after I initiate the reboot. As for why port 9 was down, that was because we hadn't reset the port yet. We did a shut/no shut to bring the port back up before doing a test 15 minutes ago. Also, this only happens to LAN ports. The WAN ports haven't experienced this problem. We haven't opened a ticket with Cisco to have someone look at the Nexus yet. We're going to try moving one of the LAN ports off the fabric extender to see if that helps. Failing that, we'll open a ticket with Cisco.
... View more
Jan 24 2022
12:04 PM
I have a very strange scenario, and I am curious if anyone has experienced this or has some insight. I deployed two MX95's in warm spare. There are no other Meraki appliances (MS or otherwise) in this network. They're connected to a Nexus switch, but on separate fabric extenders. This is my first time connecting gear to a Nexus switch. Each MX95 has a connected WAN (Internet 1) and LAN (LAN 9 using 10g SFP+ fibre module) port to the Nexus switch. The WAN ports are on their own VLAN, and the LAN connections are trunks. The LAN trunks are currently allowing only one tagged VLAN. When I reboot either MX95 the LAN port on the Nexus switch goes in to a BPDUGuard errdisable state. This is really confusing to me because I know that the MX appliances do not participate in STP, but they will forward BPDUs. There aren't any links other than the two in each MX95 (one WAN and one LAN in each MX). If there was a loop then I would expect BPDU Guard to trigger right away instead of when an MX is rebooted. Doing a shut/no shut on the Nexus switches affected port fixes the issue until the MX is rebooted. I contacted Meraki support and they don't see any issues with the MX95's. He checked logs in the appliance before and after I reproduced the issue. Any thoughts?
... View more
Dec 21 2021
6:47 AM
Hey all: Say I have these two objects: Object1 = 192.168.1.0/24 Object2 = 192.168.2.0/24 Say I have an MX64 with two VLANs: VLAN1 IP = 192.168.1.1/24 VLAN2 IP = 192.168.2.1/24 Say I don't want these subnets to talk to each other. Could I make an object group including both the above objects and then use that group as the source and destination in a deny firewall rule? It makes sense to me, I just haven't done it before on Meraki.
... View more
Nov 30 2021
11:55 AM
Thanks for the reply. I didn't think of that. Have you done something like that before? I just assumed that the dashboard wouldn't let me configure a 1:1 rule like that. Edit: I did some digging on this. The dashboard let's me configure the same address for the public and private IP. Also, I stumbled on a reddit post where someone did this. My only issue now is that there isn't a way to filter traffic other than identify which source addresses are allowed. For example, I can't filter out all traffic except a handful of TCP and/or UDP ports. Would it be better to use the 1:Many NAT instead and forward the specific ports that communication is allowed on?
... View more
Nov 30 2021
11:37 AM
Hey all: I'm planning to swap out an existing non-Meraki device with an MX95. Some of the devices behind the existing firewall have public IPs. The internal interface on the existing router has a public IP also, and that's how those devices get out to the internet. So they still go through the firewall, but they aren't NATed. I'm trying to figure out how to make this work. I know that I can get Meraki support to enable a No NAT beta feature, but I'm hesitant to do so. Lots of the MX features are in beta, but this one is so beta that support has to enable it. That makes me nervous and not want to go that route. Does anyone have an idea that doesn't involve the No NAT feature?
... View more
Nov 9 2021
3:54 PM
Thanks for the quick replies all! That's too bad that I can't block that from the firewall page. That seems like the most logical place to me. I tried applying a group policy to the client and that worked as expected. Another reason I wish the "firewall rule" way worked is because those can be logged. I don't see an option to log hits on Group Policies.
... View more
Nov 9 2021
3:08 PM
Hi all: Does any one know if Port forwarding rules are affected by Firewall rules? Say I configure a port forwarding rule (on an MX with its WAN interface directly on the internet) to forward TCP 22 (SSH) to a server on a private subnet connected to the MX. Then say I don't want someone from 1.2.3.4 to SSH in so I create a firewall rule that looks like this: Would someone from 1.2.3.4 still be able to SSH in? I tried something like this, but with RDP and I could still RDP in even though I had a firewall rule preventing any source IP and sourcing from the RDP port to my public IP and it still worked. It's as if the firewall rule isn't considered because of the port forward rule.
... View more
Apr 16 2021
7:34 AM
Thanks for the replies all! It sounds like migrating while running the routers in parallel is the best way to swap this out. Thanks again.
... View more
Apr 15 2021
7:39 AM
Thanks for the reply @DarrenOC. The reason I setup this scenario is to mimic an existing customer's network except their network has 5 spokes which are a mix of 881 routers and 5506X ASAs. The hub is an ASA. They want to slowly convert all these devices to Meraki firewalls. Would it be better to start with the spokes? As more devices are converted then I could use AutoVPN to connect those sites together, but also configure each site to do a non-Meraki VPN with the hub. Then once all the spokes are MX's, I could convert the hub to an MX and connect all sites via AutoVPN.
... View more
Apr 14 2021
2:07 PM
Hi all: The network I'm working with is detailed in the attached JPEG. There are two sites with Cisco IOS routers and a third site with a Meraki MX64 firewall. I configured a VPN between the routers and the MX64 where the MX64 is the hub and the other routers are spokes (see dashed yellow line on diagram). Hosts connected to the routers (PC1 and PC2) can ping devices on the MX64 (PC3), and PC3 can ping back. However, PC1 cannot ping PC2. The routing table on the MX64 shows both 10.0.11.0/24 and 10.0.15.0/24 networks as available. That would make sense since pings work. There is one firewall rule only on the 'Site-to-site VPN' configuration page, and it's allowing everything. Is this a limitation of non-Meraki VPNs?
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 1653 | Jan 31 2022 1:57 PM |
© 2024 Cisco Systems, Inc.
