This is a very old thread but I can confirm that today, 9.21.2023, this happened to two of our networks when we added into inventory a 2nd MX appliance, we didn't even set it up as a warm spare yet and the network traffic reset. ... View more

You will have "Allow clients to access the LAN" set to Deny in the Wireless - Firewall & Traffic Shaping section for that SSID. ... View more

Upgraded to 16.14 and its been a nightmare the uplnks from one of the switches failed to both mx100s, iva had to use standard ports now. waiting for new sfp transceivers. However now i am on has anyone configured anyconnect vpn to run on the same network as the client vpn tool ?  ... View more

There it is! I was not aware of the Wireless Health. Perfect, thanks! ... View more

Thanks mate. I figured that was the case but wanted to confirm I wouldn't be stuck in the water if I did buy a USB modem. You'll be glad to know that there will definitely be MS and MRs scattered around the site. 😉 No MT's and MV's yet but never out of the question. ... View more

Thanks @Paul_H, I'm going to try Philips method first and will come back to this if I can't get that working. Thanks again! ... View more

The AnyConnect option looks awesome, just not for the reasons my search for a solution brought up this result, as our needs would be - like the original poster, I believe, be completely satisfied with a simple option to "use existing VLAN" for the remote client's VPN tunnel.   In our case, we have two separate WAN links to the branch site in question, but all of our employees that use client VPN connect to our main datacenter network to facilitate that need.  Most of the resources they need are located there, regardless of their de facto "home" office they are physically associated with, and the routing/mesh network afforded by the Meraki configuration provides them the ability to print to their respective branch should that need arise.  All very neat and easy to configure and support, which is one of the many reasons I love Meraki.   Where we run into an issue is that at some of these branches we have a separate industrial/PLC network that is supported by a 3rd party.  This 3rd party provides their own router/firewall, but ends up using a tertiary ISP that unfortunately eschews the load balancing and redundancy available from our MX.   As I compile options for improving the overall service and mean-time to resolution in regard to problems with that 3rd party's network, I see that if I could simply designate a small pool of addresses from the same VLAN/subnet used by this 3rd party network, I could kill all these birds with that one stone.  The requirement to segregate the client VPN subnet from an existing subnet is the sticking point here.    If it's not precluded by some internal mechanism or design consideration that is hidden from view, it would be really convenient and welcome to have the option to allow it for use cases like ours.  By forcing me to route between two VLANs no matter what, I have to attempt to coordinate with a 3rd party that isn't super receptive to one-off configurations, and certainly not fantastically consistent in their documentation and retention of such configurations.  This ultimately results in the complication of future support efforts as they attempt to directly access those static IPs on the PLC network. ... View more

We have had a similar issue with a couple of misconfigured sites.  Turned out to be the mtu setting on the path to the site from radius.  The isp’s kit was configured to a figure below 1473. The first packet would be returned by the radius server but the remaining packets of 1500 size would fail. A quick check is a mtupath tool.  Next time it’s happening try this from either end to confirm if this could be the cause. ... View more

Thanks all for your great help. It's nice to hear feedback from the field. ... View more

@Paul_H    I appreciate you taking a stab at answering, and also can appreciate that you have once felt my pain before being brainwashed.  😉   Listen, I know it isn't easy; and I understand the Meraki MO of "simplicity".  But I think you have to ask "simple for who"?  I can tell you there is nothing simple about a 60 min call (on hold) to get Meraki to enable DH 14.  There is nothing simple about the fact that none of my engineers can tell that DH 14 is enabled on a firewall without ANOTHER 60 min call to Meraki support.  There is nothing simple about the fact that most of us don't even know WHICH phantom options even exist - no publicly documented list that I'm aware of.     I know managing features across different hardware models isn't easy.  But have you ever heard of a little company called Ubiquiti?  They have figured it out.  ...AND they don't even charge a licensing fee.  ...AND their hardware is a fraction of the cost.   So, with all due respect to someone who was once in the trenches with me...  I have two points: 1.  Meraki may look at feature requests, but until that feature request dashboard is public and we can all vote on them and see the rankings, I don't believe that it has the development weight that it is proclaimed to have.   There are too many features that people have had to beg for too long to have implemented (or are still waiting for). 2.  You have the budget to figure this out.  Simple doesn't have to mean "dummy proof".  Simple doesn't have to mean "one size fits all".  It isn't like you are Apple selling an iPhone to a wide audience from senior citizens to children - needing to assume there is no IT knowledge.  You ONLY sell through resellers.  Most of your equipment goes to large enterprise or goes through some IT consultant channel.  I'm trying to tell you what "simple" looks like for us - and I think that should influence your development decisions!   ... View more

Awesome Thank you very much ... View more

Thanks a lot for reply. This clarifies. ... View more

A layout/map of the area with buildings would be helpful to look at ... View more

Thanks again mate.   Yes, we have planned for unique VLANs in respect to the ISP-1, ISP-2 and LAN connectivity for sure.   I totally agreed to have a separate switches for WAN and LAN termination however this is one of small branch site for customer. Still, we look forward to check the different switch in subject to the availability factor.   Sincerely, i thank you for the response on time. Highly appreciated for your dedication & efforts. 🙂 ... View more

@Greyston It almost sounds like you would be better to hardwire an outdoor WAP rather than using an outlet on a wall thus avoiding contacts getting dirty.    If you are having trouble with your Meraki Rep I would look for another in your area.    Where are you located, possibly there is another community member close to you that might be able to help.  ... View more

Yep! What @cmr mentioned! The MX will be your gateway for all your devices... and it's WAN port will be plugged into your cable modem (which will give out DHCP by default) - then your MX will NAT all your network devices down stream. The FLAW with your design is the COPIOUS amount of hours you'll spend configuring, troubleshooting, upgrading, etc all your Ruckus gear O:)! An MR46 or two would be a nice touch! 😉 Cheers! ... View more

Thanks. It seems to be overpriced for just these two features. ... View more

NO NAT requires 15.3+, so while your 15.42 is not labeled "beta" it does support it and support will be able to find that documentation.   Keep in mind: This is a beta feature, and we do not recommend beta features for production environments, however, if your deployment requires the use of this feature, we recommend testing in a lab environment first.   Also, if this is a scenario to terminate a MPLS connection, we recommend using the MX in passthrough mode or terminate MPLS connections on the LAN side of the security appliance whenever possible. ... View more