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
