Connecting MX100 directly to a broadband uplink device (e.g. a cable modem) generally works, however placing a switch such as MS220 between MX100 and the broadband uplink is causing issues: the broadband uplink stops working (100% loss, no DHCP) and the switch itself disconnects from the dashboard. What are the "minimum working" (baseline) settings for the switch to get it to work between MX100 and a broadband connection?   Some of the questions that come to mind: What should the switch's VLAN be set to? What VLAN (if any), and what port settings (trunk? access? does it matter?) are recommended for upstream (broadband device) and downstream (MX100) connections on the switch? Given MX100 ports do not appear to have VLAN configuration options, should VLAN be configured at all for the switch and its ports?   Thank you!     ... View more

In multi-site all-Meraki environment with a site-to-site VPN, we're getting "TLS certificate validation failed: error 75788" errors in a specific application, when Meraki firewall is enabled, e.g.:   :STD: 2024-03-12T12:07:18.76048 ERROR 0/<Aloha01>:4 RdfServerClient [WW] Command result 'e95*****-1**c-4**1-8**b-f*********6' failed to send nsoftware.SecureBlackbox.SecureBlackboxHttpclientException: Failed to post data [SBHTTPSClient.EElHTTPSConnectionShutdownError] TLS certificate validation failed: error 75788; the connection will be terminated (100353/0x18801) ---> SBHTTPSClient.EElHTTPSConnectionShutdownError: TLS certificate validation failed: error 75788; the connection will be terminated     This seems to affect just one application out of a gazillion we use. Any idea what could be causing this?   Notes: The errors are isolated to a specific application, NCR Command Center. The application is effectively a C&C (Command & Control) center akin to MS Server Manager, it "talks" to "clients" in remote sites and asks them to do things like display the contents of a file system, execute a certain command, send a message, restart the client, etc. (tried asking on the application support forum - didn't get too far) All other applications and services do not seem to be affected, and it's a whole lot of them: active directory, RDS, vSphere/vCenter/ESXis, file transfers, etc. When Meraki firewall is temporarily dropped, the errors and the issues go away. See nothing in Meraki logs, and nothing in its firewall or other configuration that could be causing this. The issue started around February 2024, and so far we could not quite correlate it with any configuration changes or other events. The application appears to be using N Software Secure Black Box application libraries for those TLS connections. N Software does have a KB article describing the issue (thanks @alemabrahao!) - yet it doesn't explain why would cert validation work w/o Meraki, and stop working with it. I am not sure which TLS certificate is failing validation by the application. Is there a good way to figure this out? Is it Meraki's, or the the application's? Is it that Meraki firewall is dropping (very) specific TLS packets that result in failed validation? Anything to do with TLS version and Meraki not supporting some of the older, vulnerable ones? (There is this: "FAQ: Meraki Authentication to Require TLS 1.2 or Later Version" - yet it affects wireless devices only, it seems, and the devices in question are all on a wired network.) I am not the network admin - more of a generalist - but do have read-only access to our Meraki systems. Thanks for any ideas!   P.S. If no specific root cause comes to mind, would love for you to try and assist me in isolation and troubleshooting: Is there an easy way to see which certificate fails to get validated? Is there an easy way to see which TLS version is being used by the application? ... View more

Hi all,   New to Cisco and Meraki, started a sysadmin job a bit over a month ago that is heavy on networking - not something I've been exposed to before. Have a peculiar problem that we can't yet figure out - hope you can point me in the right direction.   We have a VMware ESXi server on the network that most of the other computers on the network cannot access where the connection is immediately dropped with "The connection was reset", "ERR_CONNECTION_RESET" to port 443 on the target. (Pinging and SSH-ing into it - works fine. It's just port 443.) Dozens of other ESXi hosts on the network with identical network configuration - have no issues. Just this one.   Question: on a network where all switchgear is Meraki (MS225-48FP, MS250-48FP, MX100-HW, MS220-8-HW, MX64, etc.), how do we figure out where that connection is dropped, i.e. which device and which policy?   Some context: Only port 443 (i.e. https://<IP address>) appears to be affected. ICMP, SSH (port 22) - work fine from the same machine that cannot access port 443 on the target. Some hosts on the network - can access port 443 on the target, and some (most) - can't. Changing the target IP address (in case there's a policy selectively blocking that IP from various parts of the network) didn't help. Changing the ports on the switch to which the target is wired (in case the ports are misconfigured or have a blocking policy we somehow can't see) - didn't help. Resetting the network configuration on the ESXi (via "reset to factory defaults" and then setting the static IP, gateway, etc. to what they were before) - didn't help, same exact behavior. My usual MO in a case like this would be put the host in a known good subnet and test there. I haven't yet tried it as this requires some help from my fellow IT people - yet my hunch is that the box itself is fine and the issue is outside of it - likely in the switch or other network configuration. We have dozens of identical ESXi hosts on identical hardware connected to identical switches with identical policies - and they all have no connectivity issues. There is even an identical ESXi host physically right next to the problematic one, on the same subnet, wired to the same switch, with an identical DNS and network configuration (with the exception of the actual IP address, of course) - no issues. The problem is quite critical: our VCSA (vCenter appliance) can't connect to the ESXi host over port 443, and thus it's effectively offline. Per my IT team, the problem has existed for a while. They had other things to work on, and I was basically handed this issue knowing very little about the network configuration, what can cause such an issue, and how to troubleshoot it. I.e. "here is an issue; go fix it". Tools available to me: Meraki dashboard with read-only access to the entire network configuration including individual ports. I can ask my network admins to make changes (but can't make them myself). Physical access to the rack where the hardware is located. Questions: Where in Meraki dashboard could I see events, log entries indicating a connection to port 443 on the target was dropped (if one of the Meraki devices or policies is responsible for it)? If this is the right question to ask, would you be willing to help me craft the right search criteria to ID those events? What are the usual best practices in troubleshooting this type of an issue? What are the usual tools used to pinpoint which device or policy is responsible for dropping a network connection to a known good target? E.g. I am trying to access port 443 on a specific IP from my desktop, there are 4 switches in-between, the connection is not working (dropped). If I connect directly to the target (with a crossover cable or something) - it's fine. How do I figure out where on the network the connection is dropped, i.e. what is responsible for dropping it? (trace route, ICMP, SSH indicate no issues in the network connection) If none of the above questions is the right one to ask, what would be the right question(s)? 🙂 Thank you! ... View more