Hi   We've come across a very strange issue that I thought was worth sharing with the fine people in the community.   Scenario is - MX68 HA pair running 15.42.1 connected to two Cisco routers, each with a fairly decent FTTC internet link - running with load-balancing switched on. Site has a cloud VOIP solution (Telcoswitch)   Router connected to Internet 1 develops a problem, is rebooting every 6-8 minutes. We raise a fault with our ISP and start the process to get the line/router checked.   All applications at the site are fine, except the VOIP phones. They can't get a stable registration, even though all the signs are that they're using the public IP of the working link.   We set internet 1 to be 'disabled' in the MX config, which we think will force all traffic to the working internet 2, regardless of the up/down state of the flaky router on internet 1. Again, all applications are fine, including auto-VPN, except VOIP phones.   We re-template the site, so it's internet 2 active, internet 1 unused, but still disabled. VOIP problem persists.   BT Openreach fix a fault on internet 1, and presumably reboot the router which is then stable for several hours. VOIP phones all recover, but again are using the public IP of the other line.   Router rebooting issue returns, VOIP phones go down. BT replace the router, which has now been stable for several days, and re-enabled in the Meraki config, but as 'ready' - Internet 2 is still the active link. Phones are fine.   Short version is; the VOIP system stability seems to be entirely dependent on the state of a router/link that is not actually being used to carry any of the traffic.   Only plausible culprit is the Meraki MX. We have a hypothesis that there's some kind of SIP processing in the MX that doesn't respect the enabled/disabled/active/ready state of the available links - some kind of processing order issue.   Whilst we've only seen this issue at one site it makes me worry about all of them that have this VOIP solution and multiple links - redundancy effectively creating a wider single point of failure.   Anyone seen anything like this?  Thanks for your time if you've read this far.   Andy ... View more

Hi folks   We have a couple of MX250s behind Juniper firewalls acting as Auto-VPN hubs for 150+ sites. The Juniper has static NAT between an internet legal outside address and the MX250 DMZ address in each case, and the firewall policy allows all the appropriate ports and destinations for management and monitoring outbound, and the UDP range 32768-61000 to anywhere for Auto-VPNs. This 'pinhole' approach has worked perfectly for all our sites on various types of wired internet circuits, xDSL and Ethernet. There are no inbound permissions in the firewall towards the MX250s at all.   But now I'm evaluating an MX68CW, the intent being to provide the same access to internet resources over Auto-VPN when a site has either failed over to LTE for internet access or potentially as the only internet access where a wired circuit isn't available.   We've managed to confirm that there's some form of Carrier NAT in play on the LTE networks, slightly different if I swap between different SIMs, but always with the same effect - Auto-VPN into the DC MX250s fails.   We can see the MX250s attempting to create outbound UDP connections to the MX68CW LTE interface on ports below 32768.  Having widened the outbound UDP port list to effectively UDP port 'any', it still doesn't work.  It looks like we have to allow some inbound traffic through the Juniper for the Carrier NAT interference to be untangled and for Auto VPN to establish.   I know it works fine if we have an anything-in/anything-out policy in the Juniper, effectively making it just a NAT passthrough, but I'd like to define only the specific policy required for Auto-VPN over LTE to work, if possible.   Anyone seen this before, and can advise how they tackled it?   Thanks in advance...   Andy     ... View more

Hi Gang   My company is half way through rolling out Meraki MXs to 200 or so branch sites, replacing the previous MPLS network, using MX68s in smaller sites, MX68 HA pairs in medium sites and MX100 HA pairs in the largest handful of sites. All sites have multiple internet links, of various types and speeds.   We always had in mind to use the beefier MXs and fast, redundant fibre connectivity in those largest sites as sort of consolidation points for onward site-to-site VPN connections to 3rd parties, including in this case our own Azure presence.   (We also have some MX250s deployed purely as VPN concentrators in our legacy datacentres, which are due to be closed by the end of this year.)   I have an MX100 configured as an Auto-VPN hub, so it has routes to all our other pure-spoke branches, as well as the datacentres via hub-meshing. That device also has a non-Meraki, IPSec site to site VPN peer in Azure - just a basic Azure VPN gateway, not an appliance or virtual MX.   But to my astonishment I can't share the route to the Azure subnet, that is present in the MX100 routing table, into Auto-VPN so other sites can access it.   I can't create a static route into the IPSec site-to-site tunnel because that insists that the next hop be layer 2 adjacent. The 'Private Subnets' setting in the non-Meraki peer config does add the route to the device routing table, but there's no option there to put it 'In VPN'   I'm aware that one workaround for this is to implement separate MX gateways for the two types of VPN and use static routing between them on local interlinks, but that seems rather wasteful and I'm bound to ask, if I had a requirement for a pure IPSec VPN appliance, why would I choose a Meraki for that?   Using vMX(es) in Azure would solve these problems, but there the limitation of 250 concurrent VPN tunnels could be a problem - our 200 sites are configured as Active-Active for Auto VPN, so we'd potentially need multiple vMXes and then have to deal with balancing our sites across them, and manage return path routing from Azure.   Has anyone run more than the nominal limit of 250 VPNs on a single vMX100?   cheers   Andy Gray ... View more

Hi Meraki folks   My first post!  I'm a network engineer for a UK charity who're about to embark on a rollout of MXs to all our sites, moving from MPLS and centralised firewall to direct internet access and distributed security/SD-WAN. It's a big project with tight timescales but it's a real opportunity to optimise the network for our migration of all our applications to the cloud. All to be completed in 2019 - no pressure then! But we're excited to be joining the Meraki family.   My question is - can the MX only support one Content Policy?   If I want to provide different content controls on a per-VLAN basis, is Layer 7 firewall group policies and a VLAN to group mapping the only way to do it?   Also, it would be really handy to apply more than one IP address to an MX internal L3 interface to aid transition from our old to new WAN termination - what would be a secondary IP address in traditional Cisco.   Does the MX support anything like that? Thanks in advance. Andy Gray ... View more