About Brash

Brash · ‎09-27-2021

I'm migrating a remote site from full tunnel MPLS to internet only split-tunnel SD-WAN. Currently, the site has a Cisco 800 that sits as the network gateway and routes all network traffic to the ISP router (via a /30) and onto the MPLS tunnel I would like to stage the migration by bringing the MX up to replace the Cisco router as the gateway to the existing MPLS WAN, and then once the ISP has provisioned the internet connection, switch over to the internet connection and utilise Auto-VPN. By that time I'll have also setup the concentrator at the primary site. I'm thinking through the process and have settled on two options: - Switch the MX to No-NAT routed mode with MPLS connected on the WAN port. Then for migration, replace the MPLS connection with the internet connection (on the WAN port) and enable NAT on the MX. - Bring up the MX in NAT routed mode with the MPLS connection on a LAN port and add a static route for all network traffic to route there. Then for migration, connect the internet connection to the WAN port, remove the static route and remove the MPLS LAN port connection. My question is, would either/both of these options work, and will there be less pain with one over the other?

Brash · ‎09-26-2021

Thanks mate. I figured that was the case but wanted to confirm I wouldn't be stuck in the water if I did buy a USB modem. You'll be glad to know that there will definitely be MS and MRs scattered around the site. 😉 No MT's and MV's yet but never out of the question.

Brash · ‎09-26-2021

I'll soon be fitting out a site with a new MX75 and am investigating options for a 4G backup. I'm aware that Meraki had a compatibility matrix here for supported modems but it seems like the list has been removed. 3G/4G Cellular Failover with USB Modems - Cisco Meraki Is this a push for people to purchase their MG product instead? Additionally, does the MX enforce that only listed USB modems will work, or is it just a list of tested and verified compatibility?

Brash · ‎09-22-2021

It sounds like your clients are getting de-authorized. Wireshark would be a good place to start to see who is sending the client the deauth. There's other tools (both paid and open source) out there which dig further into WiFi analysis. You should be able to find some with a few google searches and checking some forums. I can't personally vouch for any as I've never had to use anything more than Wireshark.

Brash · ‎09-22-2021

Good to hear you were able to make some progress. Dropping the MTU on the Meraki switch shouldn't have made a difference. It just needs to be the same as or higher than the MTU at the source and destination endpoints. When working with MTU, also make sure to check whether the value to be input includes the Ethernet header or not. From memory ESXi takes the payload size (9000) but some products will expect payload+header (9216). One other test you can do is path isolation. Do the eui's in the latency alerts indicate a specific destination or path? I don't remember off the top of my head if they're path specific or device specific identifiers. If you have the ability to do so, you can isolate down to a single path and then work your way up re-enabling additional links/paths until you hit issues.

Brash · ‎09-21-2021

The only reason I can think of DHCP being recommended is for ease of initial configuration (zero touch deployment etc). If you want to stick with DHCP IP's for the AP's, you've got a few options: - Create DHCP reservations for the AP's to ensure their IP remains consistent - Rather than adding individual addresses as NPS clients, add the entire Meraki AP management subnet Of course, as you mentioned the other option is to use static IP's instead.

Brash · ‎09-21-2021

That's some decent latency. Nothing right off the bat but to confirm a few things: - Is the iSCSI data running over L2 or L3? - In regards to the MTU, did you make MTU changes on the host/storage or are you just noting that the Meraki MTU is higher than the previous switch had configured? As @PhilipDAth mentioned, definitely for any check layer 1 issues as well (speed/duplex, drops, CRC's etc).

Brash · ‎09-19-2021

As far as I'm aware, neither the Meraki nor Anyconnect client VPN's used with a Meraki MX gateway support certificate only authentication. You can however configure certificate or domain authentication alongside client credentials. Client VPN Overview - Cisco Meraki AnyConnect Authentication Methods - Cisco Meraki

Brash · ‎09-16-2021

As @Karl mentioned, you will need Meraki support to assist in enabling the No-NAT feature. You can then change this per uplink or per VLAN. https://community.meraki.com/t5/Security-SD-WAN/MX-in-Routed-Mode-with-No-Nat/m-p/44061/highlight/true#M11161

Brash · ‎09-16-2021

I don't have an MX85 so can't be of too much help here. Typically I would suggest testing using iperf rather than file copies, however given you're getting consistent results it's probably ok. Seeing a drop in performance for routed traffic vs switched traffic is certainly feasible. Typically routed traffic requires punting to the CPU for lookups where as switched traffic can be switched in hardware, often all within the same ASIC. As for whether this is expected or not though, I'm not sure. If it's an issue and doesn't meet the needs of your environment, it might be worth reaching out to your Meraki rep.

Brash · ‎09-16-2021

The "Host-based email" rule shows "Ports 25+" because it includes multiple ports: - POP3 (Ports 110,995) - IMAP (Ports 143,993) - SMTP (Ports 25,465) There may be more that I've missed but the main point is that there are multiple ports it is classifying. The "Windows file sharing" rule has a similar name and multiple port classification. However, for this rule, it lists the ports under the name.

Brash · ‎09-15-2021

The gateway for the servers will need to be the MX, unless you have a static route on the ISP router pointing 192.168.1.x/24 towards your MX. Just to confirm, which mode is the MX set up in, and can you confirm the topology with the server subnet, the MX and the ISP router? My next steps would probably be running a packet cap on esxi to determine whether it's the forward or reverse path having the issue.

Brash · ‎09-15-2021

That certainly sounds odd. Even if you destined traffic from LAN to the WAN IP, the MX should only forward traffic to the exchange server if something like port forwarding or NAT is configured. Could be worth double checking that the MX has the latest config pulled from the dashboard (under appliance status).

Brash · ‎09-14-2021

Does the MX have an address configured for the server VLAN? If not, you'll need to add a static route on the MX to reach the server subnet, and ensure there is a static (or dynamic) route on the server subnet gateway to reach the MX client VPN subnet.

Brash · ‎09-14-2021

By default, the Meraki client VPN is a full tunnel with access to all LAN subnets. I suggest checking your L3 firewall rules https://documentation.meraki.com/MX/Client_VPN/Restricting_Client_VPN_access_using_Layer_3_firewall_rules It's also worth checking the routing table on the client device to confirm that 192.168.0.0/24 is being sent to the client's the VPN interface.

Brash · ‎09-13-2021

Right! Sorry, i guess I'm the one who was confused! I haven't used SSID tunneling myself so I'm not sure whether the MR's L3 firewall rules are applied. My hunch is that they are still applicable but I'll let someone more knowledgeable comment with the correct answer 🙂

Brash · ‎09-13-2021

I think there's a little bit of confusion regarding the site-to-site VPN. The VPN tunnel itself begins and terminates at the MX device, not the AP's. Network traffic originating from the AP's will need to be routed (via Meraki or non-Meraki devices) to the MX, at which point it will be encapsulated and passed to the MX at the other site. This is the same for both VPN concentrator and routed modes. Therefore, the AP doesn't discriminate between network traffic that will end up on a VPN tunnel and traffic that won't. It simply enforces the per-SSID firewall rules configured. Also, a quick note in regards to: "Guess i am trying to get my head around how the VPN traffic will be subject to the stateful firewall when the MR Access Points has no visibility inside this tunnel." - Firewall rules on the AP are stateless

Brash · ‎09-13-2021

If I understand correctly, you're asking whether the AP firewall rules are applicable to site-to-site VPN traffic? The firewall rules present under the wireless configuration is specific to a give SSID. These rules are applied when traffic hits the AP prior to being sent over a site-to-site VPN. MR Firewall Rules - Cisco Meraki So all network traffic on that SSID will have the rules applied to them, regardless of whether it will end up traversing the site-to-site VPN or going directly to the Internet. The AP doesn't need to be in bridged mode for the rules to be applied. For example, the NAT mode configuration suggests adding additional L3 firewall rules NAT Mode with Meraki DHCP - Cisco Meraki As a point of difference, firewall rules configured under "Security and SD-WAN" are enforced on the MX device and is where you need to look at traffic destined for Internet vs Site-to-site VPN.

Brash · ‎09-13-2021

A few things to confirm: - Is it only a single guest SSID that you're seeing can reach the 192.168.1.0/24 LAN? - Are those guests receiving a 10.0.0.0/8 IP from the AP? - Are the firewall rules configured on the MX or on the MR? Are you able to provide an output of the applicable firewall rules currently configured?

Brash · ‎09-13-2021

Yes correct. I've done that here with two switchports. They are set as access ports tagging VLAN 500. As you can see, no L3 interface for that VLAN exists on the switch (or anywhere else in the network in this circumstance)

Brash · ‎09-13-2021

Right, ok that makes sense. If the traffic is not being routed, an L3 VLAN interface shouldn't really be needed (unless you have some other requirement for it). You also don't need to explicitly define the VLAN anywhere like you would in traditional switches. https://community.meraki.com/t5/Switching/How-can-I-create-VLANs-on-MS-220-switch/m-p/11117/highlight/true#M818 You would really only need to ensure: - iSCSI traffic is tagged (either on the Meraki switchport or elsewhwhere) - The applicable Meraki switchports have the VLAN allowed on the trunk You would probably also want to restrict the iSCSI VLANs from traversing to unnecessary switches.

Brash · ‎09-13-2021

I'm not sure I understand what you're trying to achieve. Is there a reason you need to create L3 interfaces on the downstream stack as well as the upstream switch? On Meraki switches, VLAN's are already present and tagged traffic can be passed by default. They do not need to be created on the switch as you would on a traditional Cisco switch via CLI. If you already have a VLAN 104 interface on the upstream switch, you don't need to create one on the downstream stack. You would configure that upstream IP as the gateway for the VLAN. If you have L3 interfaces for some VLANs (Eg, 1,3,5) on the downstream switch and L3 interfaces for other VLANs (2,4,6) on the upstream switch, then it makes sense to create a transit VLAN between the two switches. MS Layer 3 Switching and Routing - Cisco Meraki

Brash · ‎09-11-2021

Glad to hear you were able to get it resolved.

Brash · ‎09-09-2021

Unfortunately no, the device needs to be unclaimed by the original owner. Without being able to claim it into a Meraki account, there is no way to use the device. The below link outlines Meraki's standpoint on the topic Cisco Meraki Devices purchased Second Hand - Cisco Meraki

Brash · ‎09-08-2021

No-NAT is possible but I believe it still requires Meraki Support to enable. You also need to be running a semi recent firmware version - 15.x and above

Brash

Community Record

Badges