That's not something based on the price on a firewall or something Meraki does "wrong". If you actively decide to use AD, you should have proper HA designs for that in place. 😉   But of course, this is just another point of view. ... View more

Good catch @ww! ... View more

That's just the way it's supposed to be like: https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering#Patterns_for_Blocking_or_Allow_Listing_Specific_URLs https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/URL_Block_List_and_Allow_List_Patterns   "Although the URL "whitehouse.gov/blog" can be reached, the client will only be able to reach that URL. If the user tries to reach any other portion of the site that does not begin with that URL, they would be blocked. When very specific URLs are blocked (i.e. more specific than whitehouse.gov), it is advised to test the ability to reach the website. Other portions of that website may be stored in other areas of the web server, and this will cause the page to appear as broken." ... View more

Have you already unplugged the cable from your switch to that black box? ... View more

Should be working flawlessly. It's that easy: MX will be the default gateway for your configured internal subnet so it knows where to find your endpoints Your MX has a default rule, therefore connecting to the internet via black box will work just fine. They will be hidden behind your MX's WAN IP In case your endpoints will access devices located within the WAN subnet, MX will also NAT these connections, so from that "external devices" perspective, the connection will originate by your MX Routing within your inside networks will also be handled by your MX automatically ... View more

OK, now I'm getting it, thanks!   First and foremost: you don't need to connect your switch to that black box. This will be handled by your MX just fine. You just need to use the NAT feature, because the black box won't have any routing back to your subnets. ... View more

Sorry, maybe I'm in need of another coffee, but I fear I still don't get it: 😕   Your workstation has an IP address withing the partner equipment (10.193.222.128/26) and this one should reach other machines within your two subnets (192.168.12.0/24 / 192.168.13.0/24)?   To add to that: What's the IP of your MX's WAN1? ... View more

So what exactly are you trying to route? Sounds like it's something within a subnet that your MX is taking part.   Normally, one would use a transfer network for such tasks. ... View more

Just go to the "Adressings and VLANs" page and set up both static routes pointing to the switch's transfer network address. https://documentation.meraki.com/MX/Networks_and_Routing/MX_Addressing_and_VLANs#Static_routes ... View more

Taking a look at Brightcloud's reputation lookup, account.docusign.com is classified as "Business and Economy". So there shouldn't be any issue with your configuration.   Have you tried to "whitelist" your specific client and try again if it works then? ... View more

Would you be able to give us any hints about your environment? Otherwise, this ends up in pure guessing. We even don't know what kind of features you're having in place.   Are you able to resolve the hostname? Can you ping it? ... View more

If these are the only requirements, an MX is a completely vaible solution. ... View more

That'd prolly be the easiest solution! ... View more

Could you then please tell us a little bit about your setup? Is the webserver placed in the same subnet than your client?   Apart from that: is your default gateway for that server really 192.168.0.2? ... View more

A little bit of background from Merakis documentation: https://documentation.meraki.com/MX/Monitoring_and_Reporting/Security_Center   This should answer some of your questions. ... View more

OK, to go further: did you packet trace that traffic on the internet facing or the Inside interface?   If this was done on the inside interface, it looks like MX is doing everything correctly but doesn't see returning traffic from that server.   All in all, this is guessing here becuase we don't know what's sitting between yozr external facing MX and that server. ... View more

Is the packet trace you're showing done on the outside interface or inside? ... View more

That's what I call a seamless transition! 👍   I really like the new look and feel. Took me about 2 minutes to get used to it. Well done! ... View more

There's a great doc for that 🙂 https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX ... View more

There's nice document that could help you with further troubleshooting: https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Troubleshooting_Port_Forwarding_and_NAT_Rules   Have you tried to do a Packet Capture to see if the packets destined to that server are arriving on the MX's inside interface? ... View more

I wouldn't hold my breath for that (please note that this is just my personal opinion) ... View more

Sorry to say that, but whoever has proposed Geolocation blocking as a valid solution has to be taken to special places in hell.   In the age of Cloud and Nation threat actors, this is something that prevents you from the largest spam out there, but doesn‘t provide a serious layer of security. Instead, it takes you into situations like the ones you‘re describing here. ... View more

Seriously? From my point of view, the answer is really simple: Parler was shut down because they violated AWS terms and services „simply“ because they acted as an external facing platform.   In which case would such a platform have a connection to Meraki? Well, perhaps someone could host nasty stuff behind an (v)MX, but what would Meraki have to do with this? Like @BrandonS said: if I was worried about being „censored“, I‘d think about completely different things then.   On the other hand, this sounds like an „interesting“ customer. Don‘t want to get into that political discussion either. ... View more