@ShadowoftheD wrote:     If i apply this only and they still connect via WAN1, would that be fine?   That would be Asymmetric. Traffic enters WAN1 and exits WAN2. It would be better to set ANY/ANY/ANY rule for WAN2 and allow VPN Clients to use WAN1 for and "everyone else" to use WAN2. If you have two quality internet links this won't be a problem. However, if WAN2 is 7/1 DSL then this won't be an option.    @ShadowoftheD wrote:   I'm sorry could you explain "full tunneling?   Meraki VPN makes ALL client traffic go through the MX device. This means if user is watching YouTube instead of working, they are wasting your bandwidth. So for Client VPN users, limiting their bandwidth or might be necessary if you don't have strict policies in place for your network.    You can use split tunneling pretty easily with powershell scripting and Windows 10.    See this thread to look into implementation of Split Tunneling. (Thanks so much to @Nash for that script!)   -T800   ... View more

WAN1 = 1.1.1.1 WAN2 = 2.2.2.2 Main Subnet = 10.1.1.0/24 VPN Subnet = 10.2.2.0/24   1. In "SDWAN and Traffic Shaping" under "Flow preferences" make the primary interface the one you'd like to use for Client VPN. This lets say it is WAN2. (Remember that this will now make the Client VPN connect to 2.2.2.2)   2. Make an ANY/ANY/ANY traffic shaping rule so that traffic will prefer WAN1.    3. Make a 2nd rule that allows ANY traffic with source of 10.2.2.0/24 with destination of 0.0.0.0/0 to prefer WAN2.    That should work. You might also want to make a traffic shaping rule so that "localnet:10.2.2.0/24" is shaped to a per client throughput if you are "full tunneling" your traffic.    -T800  ... View more

Batch Imaging and deploying 75 computers caused pool to fill up. Count me as one more vote for a method to manually clear inactive DHCP leases.    T-800 ... View more

Great thread.    I would also recommend you add something to set VPN adapter metric lower than your local adapters. This will help with DNS resolution so that it will always try and resolve through VPN adapter first.    Based on what I see I am guessing this should do it:   (Get-Content -path $PbkPath -Raw) -Replace 'IpInterfaceMetric=0','IpInterfaceMetric=10' | Set-Content -pat $PbkPath    -T800       ... View more

If each WAN port is getting its own public IP, I don't see why this wouldn't work. Its not truly redundant, but it should work for aggregation.      I have a an MX84 that is ultimately doing something theoretically similar, but not for the purpose of aggregation.    The MX can do "private IP" routing on the LAN ports (like to an MPLS router for example), so if you don't need inspection and NAT, that could possibly be an option too. To my knowledge the default 0.0.0.0 has to go through the WAN ports though.    T-800 ... View more

I believe the ASA's were true L3 gateways, but they may not have been as picky about ARP, or basically may have just played nicely with each other. There are certainly other options as to why, but I wouldn't worry about trying to figure out why it was actually working. Move on and just fix it.   *It would be a good idea to make sure the switches are indeed operating in L2 mode with just a management interface and are not doing any routing.    For incoming services from both ISP's you would look under the "port forwarding" section of the firewall configuration page. Each of the options let you choose the up-link (Internet 1 or Internet 2), so you should be able to use both connections for different services inbound. You'll need to figure out if you which method you were/are doing for inbound connections.    For true DMZ, you'll need to define in the firewall that the "DMZ VLAN" can't talk to the internal "Data VLAN" as the "default" rule. Then make individual rules to allow communication as necessary. Meraki's essentially have all VLANS as same security zone (ASA lets you set security levels so that DMZ can't talk to zone with a higher security level)    These articles will be helpful:   Port forwarding and NAT rules: https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX    Creating a DMZ on the MX https://documentation.meraki.com/MX-Z/Firewall_and_Traffic_Shaping/Creating_a_DMZ_with_the_MX_Security_Appliance    T-800 ... View more

Lets clarify.   WAN1 = All other traffic WAN2 = Client VPN traffic   For clients to connecting to WAN2 on the MX from the outside world, you would have use static IP (or meraki dynamic dns name) of the connection that you'd like clients to connect to the connection address. There is no way to make incoming INTERNET connections prefer a wan connection.    For outbound traffic to client, make a traffic shaping rule that forces "any traffic" to "CLIENT VPN SUBNET" prefers WAN2.    By doing this you have no fail-over for VPN clients, but you have achieved what you are trying to achieve.    T-800       ... View more

Meraki uses "lifetime-kb-unlimited" and there is no way to change this. We had an issue where we were doing MX VPN's to Cisco ASA and this is what was recommended bu Meraki support. I believe this is also why Azure tunnels won't stay connected. You need an ASA running 9.1(2) or higher I believe to use this command.   On Cisco ASA you have to specify this in crypto-map:   crypto map <map-name> <seq-num> set security-association lifetime kilobytes unlimited   T-800 ... View more

That would be a slick tool, Adam. I'd settle for just a couple of Events being created, so that I could have Syslog look for the event and Alert on it.      ... View more

I had this happen last two weeks ago with MX84's on firmware 13.28. It happened to me on Apr 20th and Apr 23rd. This was with an "affected" Meraki MX84 that was scheduled to be swapped on Apr 26th. I opened a ticket with Meraki also, but didn't press the matter since there was already a replacement on hand.    Meraki Case # 02602009   Our MX84 was in a datacenter cage and nothing else on that PDU rebooted/power cycled either time. This Meraki had been in use for just over 18 months at the time of the issue.  ... View more