Hi Kriver, I've seen some stuff on the roadmap which will probably help with this. Speak to your local Networking SE to get more information on this feature, and timelines for when it will be available. If they're unsure of the immediate answer, please feel free to have them reach out to me internally and I can point them in the right direction.
... View more
MX firmware is Linux-based, so it's not called a "VTI" on our end, but functionally, it should be mostly the same: it sends traffic to an arbitrarily defined interface that maps to a given VPN peer internally, and it does so based on what route information we've learned from said peer.
... View more
I've talked with Cisco about Access Manager and also our organisation is one of the lucky ones to test this feature. I must say it's very easy to setup and will most likely be something that would be able to replace your ISE setup if your only using the basic stuff. We've only tested MAB for now, but you can connect it to Entra ID for example to work with certificates and then do fully 802.1x.
... View more
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 🙂
... View more
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.
... View more
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
... View more
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.
... View more
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
... View more
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.
... View more
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!
... View more
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.
... View more
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.
... View more
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.
... View more
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.
... View more
@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.
... View more
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 🙂 )
... View more
