I’m not sure that I fully understand what you are trying to achieve, can you provide a diagram?   Fundamentally the iBGP within the SD-WAN only passes routes within the SD-WAN, as the SD-WAN is an Autonomous System. The routes passed to your hub from the SD-WAN will be via eBGP since the hub will be a separate Autonomous System, your MPLS network to your data centre will likely be another Autonomous System, as will the data centre itself. You may be able to manipulate the ASPATH attribute on your hub BGP router, but I can’t see how you intend to use the SD-WAN. ... View more

@CarlosCoque double check your protocol on the port forwarding rule. HTTP uses TCP not UDP, the screen grab you provided shows it configured as UDP. ... View more

The General - Public IP is the IP address that the Meraki cloud sees the management traffic coming from for that device. Whereas the WAN 1 IP address is the IP address that is actually assigned to the interface - in the example it’s dynamically assigned so probably provided from the ISP from a private address pool. Since they are different I would suggest that someone or something is doing a NAT on your link (if it’s a ‘direct’ internet link, then I’d suggest it’s the ISP). ... View more

Wondering if it’s something to do with the server configuration. I’m not a web server expert but maybe the virtual host configuration is the problem? Since the web server is being accessed from the external IP address on ports 8443 and 8080 (in the URL element), maybe the virtual hosts need to be configured for those ports. (As I said, not a web server expert... just theorising). ... View more

I don’t believe you will be able to do what you intend, the way you are describing. The MX won’t pass the traffic between the two third party VPN tunnels.   Probably the best approach would be to establish a VPN tunnel between the device in Japan and the ASA in AWS so that traffic can take that direct path, instead of via the Corp Office MX. ... View more

The BGP implementation on Meraki MX is intended only for the routing within SD-WAN. It is intended to use iBGP over the WAN component, and then eBGP from a VPN concentrator head-end to the Data Centre core. If you are using BGP on the MXs for anything other than this it is likely unsupported. I don’t know of any way to influence eBGP over iBGP routes, although given that the iBGP runs over the AutoVPN, and the eBGP directly on the WAN port, I’d need a bit more information as to what you’re trying to achieve. ... View more

I’m pretty sure on the Aruba stack you’ll find VLAN 99 configured with address 172.17.99.1. If not then you should find where 172.17.99.1 is, as that seems to be doing most of your routing.   As you said, you can create VLAN 99 (make sure the MX is in VLANs mode, not single VLAN) on your MX with the IP address of 172.17.99.3/24 - assuming nothing else is using it - which will make testing easy, followed by replacement of the Checkpoint. You then need the switch port on the MX that will connect to the Aruba stack configured the same way as the port on the Aruba stack that connects to the MX - I would tend to go with a trunk, native (or untagged) VLAN as 99, allow all VLANs.   Your static routes on the MX should have a gateway IP of 172.17.99.1, so that traffic that is intended for the remote VLANs is sent to the next hop - which should be the same next hop that the Checkpoint currently uses (probably the Aruba stack). Then as you say you can test by changing the Default Route on the Aruba stack to 172.17.99.3 (it’s probably currently pointing to the Checkpoint on 172.17.99.2). You can test by trying to Ping the MX (172.17.99.3) from your 10.1.1.0/24 Corporate network, if that works you’re heading the right way. ... View more

@PhilipDAth is correct 10Base-T won’t work. I misread it - didn’t think anyone still used 10Base-T 😀 ... View more

In my experience the mGig ports on the MS350-24X switches will negotiate 10Gbps with a 10GBase-T interface - should all work fine. ... View more

@ECI_Adelaide looking at your old route list I’d suggest that your Aruba switches are doing the bulk of the routing, not the Checkpoint.   It appears that you should have a transit VLAN (likely VLAN 1) between the MX250 and Aruba switches, this is 172.19.99.0/24. The Aruba core will have an address in this subnet (maybe 172.19.99.1), and the MX will need to have another on its VLAN 1 (e.g. 172.19.99.2). You then need to set static routes on the MX for all the VLANs that come off the Aruba core - e.g. destination 10.1.0.0/16 is via the transit VLAN, so the next hop would be 172.19.99.1 (or whatever the address in the transit VLAN on the Aruba stack is). You’ll also need to make sure that the MX keeps the same IP address as the Checkpoint had in the transit VLAN, or update the default route on the Aruba stack to point to the new IP address of the MX on the 172.19.99.0/24 subnet.   It’s not an overly complex task to configure, but you need to have a sound understand IP addressing and routing. ... View more

Meraki uses a database (provided by a separate party) that allows an IP address to be mapped to country, and that is updated regularly. When you block a country there is unfortunately no way to make an exception to that block list - although I would definitely ‘make a wish’, it would be great feature to have a white-list that allows for specific URLs when a country is blocked (I’ve hit similar problems myself).   I would also pose the question with Microsoft and see if there is a way of limiting the countries that their update services will check into to, that may be an alternate way of solving your problem. ... View more

@LontzroV you’ll need to check how to create a management VLAN for your switches. The issue is that the VLAN 5 interface on the switches doesn’t have a default gateway/route. Anything which has an interface on VLAN 5, so the MX, the switches themselves, or a host on that VLAN will be able to ping the switches. However, anything remote to VLAN 5 won’t get a response since when the switch tries to respond the VLAN 5 interface has no idea of where to send the response if it’s not in VLAN 5, and it can’t send it to the Default Gateway as that’s in VLAN 1.   There will either be a specific way to create a management interface on the switches, which will likely mean there is a limit of one interface (so you’ll need to remove the VLAN 1 interface so you can change the default gateway). Or, as in the Cisco Catalyst world, you will need to create  a management VRF so you can have a separate routing table for VLAN 5 - this is addresses the fundamental problem you have of needing to routing tables (one for each VLAN).   If all the routing is being performed on the MX then you only need one interface on the switches for management, and if VLAN 5 is to be your management network then it should just be VLAN 5. ... View more

As @CptnCrnch and @DarrenOC said, this should all work fine. I’ve had a good number of customers who run just MRs with Cisco Catalyst switches, and various firewall vendors.   The main thing I’ve found that you can’t do with a MR alone is something akin to a guest anchor. You can configure a guest VLAN easily and use that, but if you’re looking for something like a Cisco guest anchor setup where traffic is tunnelled to a DMZ then you’ll need an MX (in the DMZ) to achieve this.   Personal opinion is that in most cases tunnelling guest traffic is overkill and not required, so you don’t need the MX. But I have had customers who require that extra level of separation between their corporate and guest networks. ... View more

How is your VLAN 5 configured? What are you trying to ping in VLAN 5? The experiences you were having seemed consistent with the host you were trying to ping not having a default gateway properly configured. ... View more

The MX configuration seems about right from what I can tell, so... What switches are you using? (Are they Meraki or another vendor). Have you configured the default gateway for the management interface on the switches? ... View more

Port forwarding has to be to a specific host, essentially what you are telling the MX to do is when it receives a connection request on a particular port forward that request to an internal host at a specific IP address. It would make no sense to try and forward a port to a subnet.   By default your internal hosts should be able to access the internet across the MX. The MX does PAT (port address translation) for your internal hosts to its external WAN address.   If you have multiple public IP addresses you can setup different 1:1 or 1:many NATs for inbound traffic.   Is there a specific use case you are trying to achieve? ... View more

For the MX/Z devices the only option you have for link speed and duplex is the local status page, you can’t do it through the Dashboard. And what you get on the local status page is a bit limited too. ... View more

As @ww has indicated, you need to use the API to get this information.  Depending what you’re looking for you’ll need to find the correct API endpoint. The only ‘VLAN’ settings that really exist in a Meraki network are the Layer 3 interface (assuming the VLAN has one). If you’re thinking Cisco Catalyst where you create and name a VLAN, then that doesn’t apply to the Meraki solution. On the MS all VLAN tags are passed (and you just add Layer 3 interfaces), unless you specifically block them, on the MX you do have to create a VLAN, but all you’re really doing is creating a Layer 3 interface. ... View more

It can be found here, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practices_for_Meraki_Firmware#Appliance_Network_with_Two_MXs_in_an_HA_Configuration   ... View more

@Twitch yep, what you’ve said is correct, you should be able to use private IPs on the VPLS and then NAT them to public in your data centre. You just need to give some though as to how you are going to do that. Are you going to have VPN concentrators that terminate tunnels from the remote sites, and the hand-off to other firewalls (possibly MXs) that then do the NAT; or are you going to go without VPNs which means you’ll lose some visibility into the site as all traffic gets NATed at the remote MX. You could go with a no-NAT solution at the remote sites, but then that would mean a potentially higher overhead in managing your route table - and you’ll likely need support to enable a few things. ... View more

The Group Policy is applied to the device, not the user - generally this is by MAC address. Note that the MAC address will be that of the VPN adapter on the client, so different to its Ethernet adapter. Thus if a client connects via Client VPN and directly to the MX (e.g. in an office) then it will appear twice in the client list - once for each MAC address, and so could have a different Group Policy assigned for each. ... View more

I would say it’s overkill.   I agree with @PhilipDAth around minimising the stack size, so a stack of three and a stack of twos the way I’d go if uplink fibres aren’t an issue.   Regarding the number of uplinks, unless you need 30Gbps bandwidth, or the slightly higher availability that three uplinks gives you I wouldn’t do it. I’m pretty sure that giving each switch a link to the core doesn’t reduce the ‘hops’ to the core as the uplink in the LACP bundle that is used is determined by a hash of the source and destination addresses, thus the traffic may hop to another switch to get to the required uplink in the bundle anyway. Just seems like it will cost you a few more SFP+ modules. ... View more

When you try to access the servers by the public IP address are you on the LAN still, or are you accessing them from external via the internet (i.e. the traffic is going directly to the WAN port)? The MX won’t hairpin flows from the LAN ports to the WAN IP address, so if you are on a LAN port that is the most likely reason for the timeout. ... View more