Meraki

SahandC

Hi Bucket, it isn't that NAT stops working, it's that the default route installed to the appliance creates an asymmetric route. For sites with resources that need to be accessible from the public internet, you need to either create a VPN exclusion rule to break traffic out of the VPN tunnel, or deploy the appliance as a hub to prevent the default route from being propagated.

Bucket

I am just trying to fully understand SC and what options there are. The use case here would mostly be to utilize remote access and ztna without tunneling everything. It would also be nice to force split tunneling temporarily or in troubleshooting scenarios in case full tunneling broke something. traffic exclusion is cool for that thou 🙂

SahandC · ‎Nov 12 2024

The regular MX FW are processed if the traffic is going to be forwarded out of a LAN/WAN interface (i.e. inter/intra-VLAN traffic, or internet-bound traffic). The S2S rules are processed if the traffic is going to be forwarded over a VPN interface. If the traffic is forwarded over a VPN interface to Secure Connect, the traffic is then also assessed against the Secure Connect FW rules.

Gary_Geihsler1 · ‎Aug 8 2024

I see, this challenge is one we have seen before. User education is the first answer-although one with multiple challenges of course. As was mentioned earlier, the new client ZTNA may alleviate some of this. The client ZTNA supports all ports and protocols and feels like an always-on VPN but is a different secure access method. The user experience is an initial enrollment process and then the user does not have to login when accessing private applications/resources. I created a short video showing the user experience. https://app.vidcast.io/share/50f01122-21c9-454e-ba90-7a347c8f3dd3

grepaly · ‎Apr 27 2024

Well, that is still a workaround, albeit quite a good one! You still need to realise that this is the issue, change back and forth, etc.. I have have not given up the hope that at one day this will be fixed for good.

alemabrahao · ‎Mar 26 2024

In your place, I would avoid using a Meraki Switch for a data center, due to limitations, of course. Cisco Feature Navigator can help you. https://cfnng.cisco.com/browse/switching/features

RWelch · ‎Mar 21 2024

@Bucket Well said....thank you. I concur and appreciate the input/feedback.

brianpmcp · ‎Dec 12 2023

Hi Gary, Could the VMX in passthrough mode still use BGP to propogate Azure routes?

RaphaelL · ‎Dec 6 2023

This is exactly the main part of the problem !

Bucket · ‎Nov 9 2023

The only way do deal with silent devices is by either configure the device to use DHCP or to set the access VLAN to the VLAN the device should be in, and make sure that control direction is only out in the access-policy. This way the traffic should be able to reach the device, and the return traffic should trikker authentication.

Tony-Sydney-AU · ‎Oct 29 2023

Good news everyone! This behaviour was fixed by firmware release 18.107.6 now. This solution was confirmed by @Ryan_Miles first and @jacobi50 later. Thanks for sharing!

Rob-Nuvera · ‎Oct 3 2023

That sounds right. I agree they need to just let you make the static routes needed. They do have something called VPN exclusions now that might help in some situations. If only I could figure out a rule to exclude everything except a certain IP. Then it would be doable but a stupid way to do it.

Bucket · ‎Sep 4 2023

I is 4 bytes lower on MX16.

Bucket · ‎Aug 15 2023

Meraki also uses a public IP in the NAS field when AP's and Switches probes the radius server to see if it is alive. Meraki also uses public IPs for BGP router ID's when enabling BGP and for the APs when they are in mesh. It's really strange to see these public IPs show up at seemingly random places.

Gary_Geihsler1 · ‎Jun 6 2023

The management of Secure Client in the context of Cisco+ Secure Connect can be done any of the ways you might manage the client. SecureX deployment works, MDM will work, manual distribution will work. One aspect that is unique is that every time a user does their authorization to Cisco+ Secure Connect the xml profile is updated and placed in the proper file structure. This allows the admin to make changes to the client configuration without having to do any sort of push to the end users.

Bucket · ‎May 24 2023

In the PVT today they mentioned a list of hidden features which support can enable. One of them was disabling peering between hubs. If you are receiving the same routes in both dcs it is recommended to enable this feature to avoid asymmetric routing.

Bucket · ‎May 15 2023

@Ryan_Pascoe Thanks, that makes a lot more sense. That also means the MS390 is a beast with Meraki GP compared to a C9300 with dACL, but I guess thats the advantage of using an access-list that exists locally on the switch.

thomasthomsen · ‎Feb 13 2023

I don't remember that we have encountered any issues. So I have no idea why it is still not public. Perhaps it's just one of those features that is being worked on because it might not work on "all" switches, or I'm just the lucky one - MS2xx and 12x switches here. (We all know who the "problem" switch is 🙂 )

cmr · ‎May 11 2021

@KarstenI we wanted to trunk all the VLANs that need DHCP to it as an MX needs an interface to create a DHCP scope and our main data MX pair use a transit VLAN between them and the L3 MS210 stack to keep the site to site routing simple (a class b range that is broken down into multiple class c VLANs on the L3 stack).

Bucket · ‎Feb 2 2018

Unfortunatly that's not a solution.

Meraki

Community

About Bucket

Bucket

Brian Petersen

Community Record

Badges

Re: How does Secure Connect deal with NAT rules?

Re: Is it posisble to do split tunneling for a secure connect spoke?

Re: Which ruleset is applied when? Meraki S2S vs CDW

Re: Our Onboarding Journey so far....

Re: MX Doesn't Send Gratuitous ARP on 1:1 NAT IPs

Re: MS425 vs C9300x

Re: SecurePort (formerly known as SecureConnect) - More or less secure?

Re: Azure vMX Configuration Considerations

Re: SecurePort auth timeout recovery

Re: Radius and silent devices

Re: MX95 AutoVPN Dropping

Re: Exit Hub for specific IP

Re: MTU issues after upgrading to MX18+

Re: Network Policy Server VPN authentication weird ip address

Re: Managing Secure Client

Re: Datacenter HA, eBGP to Provider and asymmetric routing

Re: Meraki MS with ISE and DACLs

Re: Named VLAN on 15.x software - How / where do I configure this ?

Re: Unique Client Identifier WAN ports connected to network switch

Re: Multi-Auth Scenarios

Re: Is it posisble to do split tunneling for a secure connect spoke?

Re: SecurePort auth timeout recovery

Re: MTU issues after upgrading to MX18+

Re: Azure vMX Configuration Considerations

Re: SecurePort (formerly known as SecureConnect) - More or less secure?