Direct answer: what is the Cisco Meraki MX105?

The Cisco Meraki MX105 is a cloud-managed enterprise security and SD-WAN appliance for larger branch environments. It combines stateful firewalling, application-aware traffic control, Auto VPN, WAN resilience, centralized monitoring, policy management, and security functions under the Cisco Meraki Dashboard. The hardware provides two 10GbE SFP+ WAN interfaces, two 2.5GbE RJ45 WAN interfaces, four 1GbE RJ45 LAN ports, two 10GbE SFP+ LAN ports, and a dedicated management interface. One multigigabit WAN port supports PoE+, which can be useful when the chosen uplink architecture includes a compatible powered device.

It is mainly used where a business wants to secure and connect a substantial branch office without operating a locally managed firewall platform at every site. It should be considered by organizations with multi-site networks, high-speed internet circuits, significant site-to-site VPN traffic, centralized IT operations, cloud-heavy application usage, or a preference for Meraki’s Dashboard-driven operating model.

The most important factor to confirm is not simply the headline throughput. Buyers should confirm the real traffic profile, security services that will be enabled, encrypted traffic volume, WAN circuit speeds, number of users and devices, number of VPN peers, resilience requirement, available rack power, physical uplink media, and the Meraki license edition required for the intended functions. A branch with a 5 Gbps internet service can still need a different design if most traffic is inspected, encrypted, or forwarded through VPN, while a smaller circuit can still justify the MX105 when port density, 10GbE handoff, HA, or growth headroom is the deciding factor.

FourTeck can help determine whether the MX105 is appropriately sized, which license and term should be quoted, whether optics or direct-attach cables are required, whether a warm-spare design is appropriate, and whether the MX105 or a newer/larger platform is the better fit for a new UAE deployment.

Where the MX105 fits in a business network

The MX105 sits in the portion of the Meraki MX family intended for larger branch deployments rather than small offices or very large campus headends. That positioning matters because security appliances are rarely selected correctly by WAN speed alone. A realistic selection combines traffic rate, device count, connection behavior, VPN use, inspection policy, future growth, and the physical interfaces required at the site. The MX105 is especially relevant when an organization has outgrown 1GbE-only edge designs and wants multiple 10GbE SFP+ interfaces without immediately moving into the larger MX250 or MX450 class.

For a UAE headquarters branch, regional office, logistics site, healthcare administration building, education campus branch, hospitality back office, warehouse hub, or multi-floor corporate location, the MX105 can act as the internet security edge and SD-WAN endpoint while the access and aggregation switching remains separate. Its two 10GbE SFP+ LAN ports can be used for high-speed upstream connectivity to switching infrastructure, while its four fixed 1GbE copper LAN ports can serve lower-bandwidth local connections or specific infrastructure links. This makes the appliance practical in environments where the firewall should not be forced to provide large numbers of access ports.

The MX105 also suits organizations that value operational consistency. Meraki Dashboard lets administrators monitor appliance status, clients, VPN behavior, traffic and events from a browser rather than logging into each appliance individually. This operating model can reduce the day-to-day friction of managing many branches, especially when templates and repeatable policy are used. It does not remove the need for good network design. Addressing, VLANs, routing, upstream dependencies, circuit information, security policy, identity integration, logging targets, and failover behavior still require deliberate planning.

A buyer should therefore view the MX105 as part of a system rather than as an isolated firewall. Its value depends on how the appliance connects to ISP circuits, aggregation switches, Meraki or third-party access infrastructure, remote sites, cloud applications, monitoring systems, identity sources, and the selected licensing model. A procurement decision made without these inputs can result in the wrong optics, insufficient security entitlement, unused performance, unsuitable high-availability design, or a difficult cutover.

Cisco Meraki MX105 key specifications

Performance references can change as firmware and testing methods evolve. For a formal design, the current Cisco sizing guidance and the intended feature set should be used rather than relying on an older single benchmark figure.

Sizing the MX105: the decisions that matter more than a headline number

A common procurement mistake is to compare the ISP circuit speed with a firewall throughput number and stop there. The better method is to model how traffic will actually traverse the appliance. Internet browsing, SaaS traffic, private applications, video, large file transfers, backups, voice, remote-access VPN, site-to-site VPN and guest traffic can each stress the appliance differently. The number of simultaneous flows, the proportion of inspected traffic, packet size distribution, enabled threat controls and routing topology can all influence observed performance.

Start with the branch’s peak and sustained internet demand, then separate traffic that will be sent directly to the internet from traffic that will be encrypted toward a hub, datacenter or another branch. A site with 2 Gbps of internet traffic and 2 Gbps of private VPN traffic is a different sizing problem from a site with a 4 Gbps internet connection that rarely exceeds 800 Mbps. The design should also account for expected growth over the intended ownership period. If the branch is adding cloud workloads, video collaboration, backup jobs, public Wi-Fi, new floors or additional business units, the useful headroom may disappear faster than the current user count suggests.

The current Cisco family material places the MX105 at up to 5 Gbps in its firewall/NGFW class and up to 3 Gbps maximum site-to-site VPN throughput. Those numbers are useful reference points, but they should not be interpreted as guaranteed application throughput under every security and traffic condition. Cisco’s sizing documentation distinguishes test methods and recognizes that traffic composition influences results. Buyers with strict service-level requirements should size to the expected production mix rather than the most optimistic laboratory condition.

User or device count is another indicator, not a hard capacity switch. A 400-user engineering office with heavy cloud sync, virtual desktop traffic and large encrypted transfers may need more edge capacity than a 700-user administrative branch with lighter per-user bandwidth. Conversely, a high device count that includes printers, sensors, phones and intermittently active endpoints may not produce the same throughput load as the same number of power users. Connection density, application behavior and security policy provide context that a simple user number cannot.

VPN topology can become a separate sizing constraint. Meraki Auto VPN simplifies site-to-site connectivity, but hub-and-spoke and full-mesh designs have different tunnel and traffic patterns. The current family datasheet lists a high maximum tunnel count for the MX105, while Cisco also notes that maximum-tunnel testing is not the same as a recommended production state under live client traffic. Organizations with hundreds of branches should therefore confirm recommended tunnel design, hub selection and expected encrypted throughput instead of treating an absolute maximum as a planning target.

Finally, include operational headroom. Security policy changes, firmware features, new ISP circuits and corporate growth can alter the demand after deployment. If the design already consumes nearly all expected throughput on day one, comparing a larger appliance or newer secure-router platform can be more economical than a premature replacement later. The right question is not “Can an MX105 pass this traffic?” but “Can it sustain our intended policy, topology and growth with sensible margin?”

Licensing: choose the feature set before you choose the term

Meraki MX appliances depend on an active licensing model, and the license choice is a core part of the purchase rather than an accessory to be decided later. Cisco currently documents Enterprise, Advanced Security and Secure SD-WAN Plus editions for the MX platform. The correct edition determines which security and SD-WAN capabilities are available, so the buyer should map required functions to an edition before approving the order.

Cisco publishes MX105-specific license SKUs for 1-year, 3-year and 5-year terms. Examples include LIC-MX105-ENT-1Y / 3Y / 5Y for Enterprise, LIC-MX105-SEC-1Y / 3Y / 5Y for Advanced Security, and LIC-MX105-SDW-1Y / 3Y / 5Y for Secure SD-WAN Plus. Cisco also documents per-device Secure SD-WAN licensing SKUs in which MX95, MX100 and MX105 fall into the large appliance tier. Because Cisco licensing programs continue to evolve, the exact model in the customer’s Dashboard organization should be confirmed at quotation time.

Organization-level licensing rules deserve attention. In co-termination and some other licensing contexts, Cisco requires consistent MX license editions within an organization. A company that already operates Meraki MX appliances should therefore identify its current Dashboard organization, licensing model and edition before adding an MX105. Buying a mismatched edition can lead to an organization-wide licensing issue or a requirement to separate appliances into different organizations.

For high availability, Cisco’s licensing documentation states that two MX appliances operating as a warm-spare pair require a single license under the relevant model. This can materially affect the business case for resilience, but the exact deployment and licensing arrangement should still be validated against the customer’s current licensing program before purchase.

Security capabilities and what they mean operationally

The MX platform combines routing, stateful firewalling, application visibility, traffic shaping, VPN and security services in a centrally managed appliance. Depending on licensing and configuration, the platform can apply Layer 3 and Layer 7 rules, geo-based controls, network address translation, content filtering, intrusion detection and prevention, malware-related protections, user or identity-based controls, and traffic prioritization. The practical benefit is that branch security policy can be operated through the same Dashboard used for connectivity and SD-WAN rather than through a separate local management stack.

This consolidation does not eliminate policy design. Firewall rules should still follow least-privilege principles, be tied to clear business requirements, and be reviewed for legacy entries before migration. Layer 7 restrictions need to be tested against business applications. Content filtering categories should reflect organizational policy. Threat-prevention features should be enabled with an understanding of licensing and any application exceptions. Logging should be planned so the security team can investigate events without depending only on a single dashboard view.

Organizations replacing another firewall should not attempt a line-by-line rule copy without rationalization. Different platforms represent objects, NAT, zones, application controls and VPN policy differently. A migration workshop should identify which policies are still required, which services can be simplified, which address objects have changed, and which rules exist only because of a previous architecture. This is often the best opportunity to remove obsolete access rather than reproducing it on the new appliance.

Security inspection also changes sizing. If the design uses advanced intrusion prevention, malware protection, extensive filtering and encrypted tunnels, the branch’s workload is more demanding than plain NAT and routing. The current MX family data indicates that advanced security throughput can approach the NGFW performance class under specified conditions, but buyers should still size using the exact features, traffic composition and current Cisco methodology relevant to their deployment.

For regulated or audited environments, define evidence requirements as part of the design: syslog destinations, alerting responsibilities, change-control process, administrator roles, authentication controls and retention expectations. Meraki Dashboard provides change logs, monitoring and integrations, but the organization remains responsible for deciding what information must be retained and how incidents are handled.

SD-WAN, Auto VPN and multi-site design

Meraki Auto VPN is one of the main reasons multi-site organizations standardize on MX. It automates much of the site-to-site VPN configuration needed to connect Meraki branches, hubs and concentrators. Administrators can define hub-and-spoke or mesh relationships, advertise local subnets, and use SD-WAN policy to influence path selection. The operational advantage is particularly strong when dozens or hundreds of locations need consistent connectivity and centralized troubleshooting.

The MX105’s current maximum site-to-site VPN throughput figure of up to 3 Gbps makes it appropriate for substantial encrypted branch traffic, but the number should be interpreted in context. A branch sending most SaaS traffic directly to the internet may use VPN primarily for internal applications, while another organization may backhaul a much larger share of traffic to central security or datacenter services. The second design places greater sustained demand on the VPN datapath even if both branches have the same number of users.

WAN resilience should be designed around actual carrier diversity, not just two ports. Two internet circuits delivered through the same building entry, carrier core or upstream provider may still fail together. Where business continuity justifies the cost, use diverse service providers, different physical paths, and—where appropriate—a cellular backup strategy. The MX105 platform supports automatic WAN failover and policy-based traffic behavior, but the resilience outcome depends on the independence of the underlying circuits.

Cisco documents that the MX75/85/95/105 hardware exposes multiple WAN interfaces while firmware governs how active uplinks and backup interfaces operate. This is a detail worth confirming before purchasing additional transceivers or circuits. If the intended design requires three provider handoffs, verify the current MultiWAN functionality and firmware prerequisites rather than assuming the four physical ports operate as four equal active WAN links.

For global organizations, route design must also consider cloud hubs, datacenter concentrators, overlapping subnets, local internet breakout, SaaS optimization, regional latency and failover convergence. The appliance can simplify transport management, but it cannot correct an addressing plan that was never designed for multi-site routing. Network discovery before rollout therefore has direct value.

Cloud management: advantages, dependencies and governance

The Cisco Meraki Dashboard is the operating center for the MX105. Configuration, status, client visibility, security information, VPN monitoring, firmware workflows, traffic analytics and troubleshooting tools are available through the web-based platform. For an IT team managing many UAE or regional branches, centralized administration can reduce repetitive device-by-device work and make standardized policy easier to maintain.

Zero-touch deployment is valuable when remote sites lack local network engineers. An appliance can be claimed into the correct Dashboard organization and network, receive configuration, connect to an internet service and establish management connectivity with relatively limited local staging. That benefit is strongest when pre-deployment information is accurate: circuit addressing, VLAN IDs, upstream firewall requirements, serial numbers, organization access and license entitlement should be prepared before the installer reaches the site.

Cloud management also creates governance requirements. Administrator accounts should use strong authentication, appropriate roles and change control. Access should be limited to the teams that need it. Template-based deployments should be tested so a configuration error is not replicated across many branches. API usage should be controlled with secure credentials and clear ownership. Alerts should be routed to monitored channels rather than individual inboxes that may be ignored.

The Dashboard does not mean the appliance stops forwarding all traffic if cloud management is temporarily unreachable; however, configuration, telemetry and management workflows depend on connectivity to Meraki cloud services. Upstream firewalls, proxies or restrictive internet access therefore need to permit the required outbound communication. Cisco publishes current connectivity requirements, and those should be checked during installation instead of relying on an old static port list.

Rack, power, airflow and environmental planning in the UAE

The MX105 is a 1U rack-mount appliance approximately 19 inches wide and 12.4 inches deep, with a listed weight of about 4.87 kg when two fans and two power supplies are installed. The relatively shallow depth fits many communication racks, but the installation still needs sufficient rear and side clearance for cables, power modules and airflow. Cisco’s installation guidance specifies side-to-side ventilation and calls for at least 10 mm clearance at ventilation openings. That detail can be missed when equipment is packed tightly between cable managers or rack side panels.

The listed operating range is 0°C to 40°C with 5% to 95% humidity. In Dubai and the wider UAE, the practical concern is not outdoor climate but what happens in the communications room when air conditioning fails or doors remain open. Edge firewalls, switches and ISP equipment can create a concentrated heat load. A branch that depends on the MX105 should provide stable cooling, clean airflow, environmental monitoring where appropriate, and a power design that supports the desired availability objective.

The MX105 uses two modular 150 W AC PSUs and Cisco lists approximately 53 W idle and 123 W maximum appliance load. For a resilient deployment, placing both power supplies on the same small UPS offers less protection than using independent protected feeds where the facility allows it. The rack’s PDU outlet type, UPS capacity and available socket count should be checked before installation. If a new rack or UPS is part of the project, include the firewall’s load in the complete equipment power budget rather than looking at the appliance in isolation.

Rack-mount screws are documented as an optional kit rather than a standard inclusion for MX95/MX105, so installers should not assume every required mounting fastener is in the appliance carton. The site survey should confirm rack type, cage nuts, screw standard, available 1U position, cable management, PDU position and service access. These inexpensive details are common reasons for avoidable delays.

Finally, keep the original packaging and order information. Cisco’s hardware support documentation notes that original packaging information may be needed during a replacement process. For enterprise assets, serial numbers should also be recorded in the customer’s inventory system alongside license term, installation date, rack location, WAN circuit identifiers and support contacts.

Deployment journey: from quotation to production cutover

A staged cutover is especially important when the MX105 replaces a firewall that also performs DHCP, static routing, NAT, remote-access VPN or inter-VLAN routing. Every one of those functions must have an explicit migration owner and validation test.

Migration from an existing firewall

Migrating to the MX105 is not simply a cable swap. The existing firewall may be performing functions that have accumulated over years: NAT rules for public services, site-to-site VPNs, remote-access VPN, DHCP scopes, inter-VLAN routing, DNS forwarding, traffic shaping, policy-based routing, static routes, guest access, identity integration, logging, web filtering and special application exceptions. The first migration task is to discover those functions accurately.

Export configuration and rule information from the current platform where possible, but use it as a source document rather than as the final design. Rule bases often contain obsolete objects, duplicate entries and temporary exceptions that became permanent. Classify rules by business owner and application, identify what is still in use, and remove unnecessary access before translating policy into the Meraki model. This reduces risk and creates a cleaner security baseline.

Public IP and NAT changes deserve special planning. If the ISP handoff remains the same, the new appliance must be configured with correct addressing and equivalent inbound/outbound behavior before the cutover. If the project also changes ISP circuits, public DNS, externally published services, allow-lists and third-party VPN peers may need updates. Changes to a public IP can affect SaaS providers, payment systems, remote partners, monitoring services and cloud security tools that restrict source addresses.

VPN migration should be divided into Meraki Auto VPN peers and non-Meraki IPsec peers. Meraki-to-Meraki sites can gain operational simplicity from Auto VPN, while third-party tunnels still require careful parameter alignment. Confirm encryption domains, local and remote subnets, peer IPs, authentication, encryption settings, lifetimes, NAT exemptions and routing. For business-critical peers, schedule joint testing with the remote party rather than assuming the tunnel will come up during the maintenance window without coordination.

If remote users depend on the old firewall for client VPN, plan the replacement client and authentication experience. Users may need new software, profiles, credentials or support instructions. Test from an external network before decommissioning the previous remote-access service. A successful office internet cutover does not mean a migration is complete if remote staff cannot connect the next morning.

The rollback plan should be concrete. Record which cables move, which circuit equipment must be rebooted, how long upstream ARP or carrier handoff changes may take, and the exact condition that triggers a rollback. Keep the previous firewall configuration available until the new environment has been validated across internet, VPN, critical applications, monitoring and failover.

Common UAE deployment scenarios

These examples illustrate fit, not automatic recommendation. A site with lower traffic may be better served by a smaller appliance, while a very high-growth site, major campus or VPN aggregation role may justify an MX250, MX450 or a newer high-performance secure-router platform.

MX105 versus nearby and newer alternatives

The correct alternative depends on why the MX105 is being considered. If the project is mainly a mid-sized branch with lower throughput and fewer high-speed interface requirements, the MX95 may provide a more economical fit. If the site needs materially higher aggregate capacity, more VPN scale or a larger interface footprint, the MX250 or MX450 may be more appropriate. The decision should be based on current Cisco sizing data and the expected production load rather than model-name progression.

The newer C8355-G2-MX is particularly relevant for fresh designs because Cisco has expanded the cloud-managed security and SD-WAN portfolio beyond the traditional MX hardware line. It offers substantially higher current performance figures and different interface characteristics. That does not automatically make the MX105 the wrong choice. Existing Meraki standardization, commercial availability, licensing, hardware compatibility, support strategy and the actual requirement all matter. But a buyer placing a new long-term order should compare both platforms rather than assuming an older model number is the only Meraki-compatible path.

Cisco’s published end-of-life list does not currently show the MX105 as announced for end of sale or end of support. That is useful lifecycle context, but lifecycle status can change. For multi-year projects, validate the current Cisco product notice and support timeline at the time of purchase.

Accessories and quotation dependencies

The hardware appliance alone is often not a complete order. A usable MX105 deployment may require a license, region-appropriate power cords, optical transceivers or direct-attach cables, rack hardware, a second appliance for warm-spare HA, and professional services for migration or installation. The correct bill of materials depends on the site.

Procurement guidance for UAE buyers

For a clean Cisco Meraki MX105 quotation in the UAE, start with the exact hardware requirement and quantity, then define the licensing edition and term. A quotation that says only “MX105” is incomplete because different license choices can materially change capability and commercial value. If the organization already uses Meraki, provide the current license model and edition so compatibility can be checked before an order is placed.

Next, identify every physical handoff. For each WAN circuit, state whether the carrier presents copper or fibre, link speed, connector/transceiver expectations, static or dynamic addressing, VLAN tagging and whether the customer or carrier supplies the optic. For each LAN uplink, provide the connected switch model and desired speed. This is particularly important when 10GbE SFP+ ports are being used because “SFP+” describes a form factor and speed class, not the complete optical link specification.

If high availability is required, specify whether the quotation should include two MX105 appliances, whether the site has diverse WAN circuits, whether there are redundant switches and whether separate UPS/PDU feeds exist. Buying two firewalls without removing surrounding single points of failure can create the appearance of resilience without delivering the expected outcome.

For replacement projects, include the current firewall model, number of interfaces, approximate rule count, VPN peer count, remote-access VPN requirement, public NAT services, VLANs, routing protocols or static routes, and maintenance-window constraints. A small branch with a complex rule base can require more migration effort than a larger branch with a clean standard template, so services should be quoted based on scope rather than device price.

Commercial buyers should also distinguish hardware lead time from project readiness. An appliance can arrive before the ISP circuit, rack power, optics or license is ready. Coordinate these dependencies so the equipment can be staged and validated ahead of the agreed cutover. If the project is linked to an office opening, tenancy handover or datacenter migration, work backward from the required service date.

For broader network and support requirements, buyers can use FourTeck UAE for regional technology engagement, FourTeck IT Services UAE for infrastructure and support services, and FourTeck for wider solution coverage.

Practical buyer questions and answers

Operational support after deployment

A branch firewall is a continuously operating service, so the project should define what happens after the installer leaves. Assign ownership for Dashboard administration, firmware maintenance, security policy changes, alert response, circuit incidents, VPN issues and vendor escalation. If the internal team does not monitor the environment continuously, decide which events require proactive support and which remain best-effort.

Firmware updates are a normal part of the Meraki operating model. Organizations should maintain an approved maintenance process, understand firmware release channels relevant to their environment, test changes where business risk warrants it, and schedule updates to avoid peak operating periods. Automatic cloud management makes update distribution easier, but governance remains important for critical branches.

Performance monitoring should focus on trends rather than isolated spikes. Record WAN utilization, packet loss, latency, VPN quality, application demand and client growth. A branch that was correctly sized at deployment can outgrow the appliance or circuit as the business changes. Trending helps identify whether the next bottleneck is ISP capacity, security appliance performance, switching, Wi-Fi, application behavior or a remote destination.

Maintain documentation outside the live Dashboard as well. An interface map, carrier account information, public IP allocation, rack location, serial numbers, license renewal details, VPN peer contacts, critical firewall rule owners and escalation matrix can shorten incident resolution. If only one engineer knows why a NAT rule exists or which carrier circuit is primary, the operational model is fragile.

Organizations seeking ongoing infrastructure assistance can combine the appliance project with monitoring, maintenance or broader IT support. The commercial scope should state response expectations, onsite coverage, after-hours requirements, vendor coordination and whether changes are included or separately approved.

Decision recap before you buy the Cisco Meraki MX105

What FourTeck needs for an accurate MX105 quotation

Plan the MX105 as a complete branch-security project

The best MX105 purchase is the one that arrives with the correct license, interfaces, optics, power plan, resilience design and migration scope already decided. Share your branch size, circuits, security requirements and current network details so the quotation reflects the actual deployment rather than only the appliance SKU.