Meraki

AlexP

To give hopefully some clarification here: Routed tunnels are built off generic traffic selectors, so they'll take whatever gets routed to them so long as a matching route exists. This does indeed mean that yes, routing between Non-Meraki VPNs and AutoVPN is possible now, in addition to being able to full-tunnel traffic from a Non-Meraki site to a Meraki one.

AlexP

If you can recall a case number, would you mind DM'ing it to me? I'd like to see the verbiage/conclusions you were provided with.

AlexP

If you don't want to, or can't implemented pushed MFA, another option is to enable certificate authentication as a second factor (or indeed third factor since it works with pushed MFA as well). To do that, you'd need a local Certificate Authority (which your Domain Controller can serve as), then generate a self-signed root cert, which you'd upload to the MX. It doesn't need to be from a commercial or otherwise publicly trusted, so long as you trust your own organization to serve as a secure root for a chain of trust. From there, you can then just start using that CA to sign certs, and install those onto your client hardware to serve as a means of authenticating your client devices to the MX. It's a bit more work, but I would also highly suggest you find a way to provide certs with unique Subjects/SANs to each of your client devices, that way you're not having to reissue a new one any time you need to terminate someone's VPN access.

AlexP

Since you have an MX84, it's unfortunately not possible for you to implement what you want owing to firmware limitations. On newer platforms that can run the MX19.1 branch, what you're asking for is possible now with routed-mode VPNs, though that also requires the use of BGP to signal a return route back across the tunnel for any clients on the non-Meraki side of the tunnel

AlexP · ‎May 1 2024

Hey folks, This is a well-known consequence of DTLS negotiations failing: https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html If it's not a huge issue to your users, it's relatively harmless to leave it be, but if you want to fix it, make sure your appliances are reachable on UDP 443

AlexP · ‎Apr 26 2024

Unfortunately this won't work - if you're trying to manually apply policies to the clients in question, it only lasts until they disconnect. I would recommend that OP use AnyConnect instead, and deploy it with a profile that restricts what these contractors have access to by only telling it to route traffic destined to the VLAN in question over the tunnel, and nothing else.

AlexP · ‎Apr 15 2024

The root of all the problems you're likely facing is that many, many websites cross-load content from other domains, and won't render properly until everything is done loading. If it happens that one or more of these domains are blocked by an L7 rule, you'll see things appear to load slowly because the request is being retried (and blocked) until eventually the page decides to let the request time out. A few years ago, I published a case study on how to more clearly identify and resolve these sorts of issues: https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_HAR_Files_to_Troubleshoot_Web_Pages_that_are_Failing_to_Fully_Load With that being said however, ultimately what our Support Teams have been saying is correct. We don't control the updates we get from Maxmind, or why they render the verdicts they do, and this can make these rules fragile because of cross-loaded content.

AlexP · ‎Mar 7 2024

You need both, because the preshared key is what authenticates your users' devices and your MX to one another. The username/password is required to authenticate the users themselves

AlexP · ‎Mar 1 2024

Packet loss could easily be the cause of reduced performance though

AlexP · ‎Feb 29 2024

Hey Boyan, Can you Direct Message me your case number? I'm curious what Support is claiming to see on these and want to take a deeper look.

AlexP · ‎Feb 13 2024

The best way to troubleshoot this is to start a packet capture, and then start your file transfer; there's a few details Support can reference in such a capture to help determine where it's bottlenecking better.

AlexP · ‎Dec 20 2023

@RaphaelL wrote: This is allegedly an expected behavior. Yes and no. All Meraki devices utilize what's known internally as a "safe config" to fall back on in the event that a prolonged outage occurs after a change. Current running configs are copied/rotated into the safe config after 4 hours.

AlexP · ‎Nov 16 2023

To be clear here, manual NAT-T only works for the purposes of AutoVPN, and a port forward on the MX itself wouldn't resolve the issue either. Realistically, if Starlink offers any way of doing a fixed inner IP or some other way of allowing for inbound traffic through the outermost layer of NAT, that might also be a solution for you.

AlexP · ‎Nov 16 2023

To hopefully give some slightly more technically precise answers here: We have no explicit option for "idle timeout" that would do something like prompt us to send a DELETE message to a non-meraki peer that would tear down an established tunnel. For IKEv1, the tunnel will be torn down after the lifetime expires, unless interesting client traffic has already prompted a rekey beforehand, or, if DPD is in use, after the peer stops responding to any R-U-THERE (yes, that's really what they're called) packets for too long. For IKEv2, owing to changes in how the protocol operates, DPD is mandatory. However, by default, we won't send any DPD informational messages unless there is no client traffic traversing the tunnel (but will still ACK any DPD messages we receive from the peer in question). Otherwise, the same rules with lifetimes continue to apply, though it's also worth noting that since IKEv2 no longer requires equal lifetimes on each end of the tunnel like IKEv1 did (again, this is a change in the protocol itself, not one we forced), you may see a tunnel getting torn down as a result of a DELETE message getting sent by one peer to the other, rather than being logged as a lifetime expiring.

AlexP · ‎Oct 13 2023

Currently, there are a few known issues with fragments not properly getting re-assembled when IPS is in use that could be at play. Depending on the forwarding path in question, you may also have positive results if you drop your MSS/MTU on the service a bit lower than 1500, especially if captures of traffic before it hits the MX indicate there is network-layer fragmentation occurring.

AlexP · ‎Oct 13 2023

This is correct - the exact semantic details are still being worked out, but you can expect to see changes soon (and apologies, I can't get into more specifics as of when). What I can say, since it's already reflected in what versioning you see already to an extent, is that it will be a 4-point system. We can't currently display it as cleanly as we'd like yet, but as Ryan already alluded to, our current release of 18.107.5 is actually meant to be 18.1.7.5

AlexP · ‎Oct 13 2023

To be explicit here, yes, ECH will pose a problem for some features on MX. Explicitly, Content Filtering relies on being able to see the domain the client is attempting to communicate with, which is contained in the Server Name Information (SNI) field of a TLS header during the initial handshake. This works just fine for TLS 1.2, and TLS1.3 when ECH is NOT in use, but any extensions to TLS1.3 that obfuscate this information will prevent it from functioning.

AlexP · ‎Sep 28 2023

It's supported in all major versions 16+, so 18 would be our recommendation

AlexP · ‎Aug 9 2023

Hey Tor, I would suggest opening a Support case about this, and providing them with a DART bundle taken after a failed connection attempt, with the timestamp (and time zone) of the failed attempt noted. We should be able to get a more detailed reason as to why the request is still failing from there.

AlexP · ‎Aug 8 2023

Since we have our own CA we autoenroll a Workstation template based certificate to the end user's device. If that CA is the one signing those client certificates, the assumption is that it also has a self-signed certificate to provide the root of the chain of trust defined in those client certs. If that is the case, that self-signed root is what needs to be on the MX to validate the certs the clients are presenting when they log in.

AlexP · ‎Jul 25 2023

This is not true unfortunately - MX64s, 65s, 84s, 100s, 400s and 600s do not support the use of TLS for management traffic, and there's no way for support to override this (due to reasons I'm not at liberty to disclose)

AlexP · ‎Jun 23 2023

Please let us know if you're still seeing them by EoD today - if you want to suppress the alerts, it's safe to add the signature to the bypass list in the mean time

AlexP · ‎Jun 21 2023

Hey folks, After raising this internally with our findings, TALOS has informed us that they'll be removing this particular signature from the ruleset they share with us. To be clear, this only ever referred to a very old vulnerability from 2005 that could be triggered if a packet with a certain data structure was seen in its Layer 7 (application) headers, so we don't foresee any harm in its removal. We cannot say with certainty given the difficulty in obtaining the packet that triggered this for everyone, but the most likely reason is just pure happenstance: a genuine service just happened to send a packet that matched on this signature without meaning to. This could have happened because there's a genuine case for said packet whose structure was ill-handled by Kaspersky back in the day, or this simply being a signature that was too broadly defined, akin to a regular expression that's too greedy and matches more text than you want it to. Either way, that is the full extent of what we believe can do to explain the nature of this, and prevent it from reoccurring.

AlexP · ‎Jun 21 2023

Hey, This could be true if this were getting blocked by AMP, but Snort does not inspect binary payloads like .cab, .exe, etc files - it only does deep packet inspection looking for specific data patterns within the application headers.

AlexP · ‎Jun 16 2023

Hey @etb NBAR is not used with Snort at all - the definitions come from what we load from TALOS. If folks are seeing an upswing in this traffic, there's really not a lot our support team can say beyond "the MX received traffic that matched the signature in question" For what it's worth, the signature in question does correlate with a very old CVE, so I don't believe it should provoke any concerns beyond simple noise: https://nvd.nist.gov/vuln/detail/CVE-2005-3142

About AlexP

AlexP

Community Record

Badges