Ah ok, because that is the router and it is the gateway to the networks, it is always better practice to configure control policies there. On the MX Firewall Configuration section, just apply the rules which you were applying to the switch. This should get it working for you.   As always, I recommend you do this during a suitable time frame as you may cause network disruption that is unexpected for some end users.   Thanks, Daniel. ... View more

All good mate, hopefully we get there in the end and sort out this problem!   I am not so sure why that is not working. Just to confirm when you mentioned at the start the vlan's were on the switch, I assumed that you mean that the switch has configured the Layer 3 Interfaces for the VLANs and are routing the traffic to a router which maintains the internet (WAN) connection. Is this the case or is there a seperate device like a ISP provided router or your own managed router? Also just to confirm, with this Meraki switch are all the devices in both vlan's connected to this switch either directly or into another switch connected to this switch? ... View more

@PaulCoad  I believe it is an issue with your VPN configuration of the adapter on your computer since you have DHCP disabled.   Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Prospira Physical Address. . . . . . . . . : DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 10.12.99.53(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 0.0.0.0 DNS Servers . . . . . . . . . . . : 10.12.61.78 10.12.61.79 NetBIOS over Tcpip. . . . . . . . : Enabled   1. Your subnet is a /32 subnet. 2. You have no default gateway.   The reasons why this problematic.   1. With a host subnet (/32) subnet it effectively means it thinks it the only device in it's own little network. If your VPN network is a /24 network, then you should see a subnet that matches 255.255.255.0 . Which if you look at your servers interface that is what is configured for it's subnet. This type of configuration on your adapter for the subnet is what we call a host /32 subnet. It is typically configured on loopbacks used for management or monitoring, it shouldn't be used in this scenario. You will just need to review your manual adapter configuration and either set to DHCP or configure an ip address and subnet mask that reflects the VPN network.   2. No default gateway means your computer does not know an entry or exit point to the rest of the world effectively. It has no gateway. This also is configured manually on your network adapter or also received via DHCP. You can manually put in your gateway here, such as the VPN network interface configured on the Meraki MX - 10.12.99.1   Let me know how you go with this Paul and I hope this gets you going!   Thanks. ... View more

@gplatret-   Your first rule to allow access to the gateway is redundant because we are just blocking access between VLAN's and all other traffic not specified is allowed.   The second rule (the vlan deny rule) will not work in it's current form and will block all access as the destination is set to ANY. Since all you have advised me here is that you want to block access for each data vlan to talk to each other you need to make a rule in summart that does this.   1. Rule 1 - Deny Traffic from VLAN1 to VLAN2 2. Rule 2 - Deny Traffic from VLAN2 to VLAN1   Within Meraki, you need to include the Source Address and Destination addresses for each respective rule and then select Deny. So for example, this is what it should look like. Obviously remove the addresses I have put in and match it with what the networks are configured for your environment.     Let me know how you go mate.   Thanks. ... View more

@gplatret  I am assuming the router is connected to some other gateway or router and you want to manage everything on the Meraki switch instead.   You can restrict network access between these two VLANs by the tried and true method of ACLs (Also Known As: Access Control Lists). Follow this guide in setting it up - https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs   With Meraki all traffic not specified here will be allowed. So as per the guide, if you configure your first rule with the destination of data VLAN 1 and the source data VLAN 2, you will find that traffic from data VLAN 2 will not work. You will then make a similar rule for destination VLAN 2. As a precaution since I am guessing this is your first time doing this, I would encourage you do to do this at a time when it will cause minimal disruption if this switch is in a work environment.   Let me know if you get stuck and or if this does not make sense.   Thanks. ... View more

Hi Deepak (or can I use Deep for short? Feel free to call me Dan 🙂 ),   Yes I encountered this problem with a previous company I worked for. Meraki are still working on doing standard routing protocols through their dashboard. It's best to consider and think of MX's in their current form a NAT Gateway, it helps in how you choose to deploy them.   Viptella was acquired to provide SD WAN and provide these more advanced enterprise grade features.   The solution we had to implement was putting two (for HA) Cisco ISR's to manage the L3 routing protocols and to the Meraki it just saw the ISR's as it's internet link, so when data came from the SD WAN Meraki spokes, intending to reach a private subnet on another router through a site to site VPN connection it was sent out the Meraki's WAN connection. When packets reached the ISR's they then routed the traffic over that traditional IPSec Site-to-Site VPN. Traffic was routed back to the SD WAN in a similar but different fashion. Now if you don't want to use Cisco ISR's, you don't have to. You just need some other type of router in front to establish the site to site VPN and to manage the BGP (or whatever WAN L3 routing protocol you choose) routing advertisements and redistribution back to the SD WAN Hub (MX device). Also you will want to ensure whatever device you end up choosing to do this is capable to manage the amount traffic you expect now and in 3 - 5 years time to traverse the device.   A good article which explains it really well is this one - https://www.willette.works/merging-meraki-vpns/   So depending your preference and what you are comfortable with you could achieve it in a few ways, but you cannot do it exclusively with the one Meraki MX unfortunately. There will be a time in the future maybe that Meraki enable this, I cannot help with advising if and when this will happen, I wanted it over 6 months ago! Haha!   Thanks, Daniel. ... View more

I am guessing this is because you wish to route traffic to and from another remote site through a traditional routing protocol? ... View more

@gplatret  - That link is specifically for an MX, it will not be helpful unfortunately for you if you want to make changes on a Meraki switch. If you would like to do this on your Meraki Switch, you will need to follow these instructions. - https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing   However I do need to understand further what you mean, you are asking to seperate the data vlan's. From my point of view the English wording you are using here is not helpful, I mean that in a sincere way as I understand that English is a difficult language.   So to clarify with you and ensure we are understanding each other. The purpose of VLANs and their nature is that they provide a layer of network seperation. We create VLAN's to keep traffic isolated based on their purpose. This does not however prevent access to those networks. In order to do this we need to implement some sort of control mechanism.   SO before I explain how we can do some form of control mechanisms with Meraki, can you clarify if the word you are using - "seperate" means either; 1. To create new VLAN's that will be able to contacted by all other networks (vlan's) within my network. 2. To create a control mechanism to prevent access between the two data vlan's so people or servers in each of those vlans cannot communicate with each other.   Thanks, Daniel. ... View more

Hi @PhilipDAth    Not Meraki related at the moment, though in the next 2 weeks, I will be beginning the DevNet track on Meraki, and building a project from there.   For the next two weeks I have started a project to tie together 6 weeks of initial Ansible learnings into something that could be practical in a work place. I am going to be doing this project with Ansible, but this is the first step in my long term ambition to be proficient ultimately at network automation through Ansible & Python. I am starting with what is immediately easy and relevant to my current job as Ansible I can immediately start leveraging as it is used at my work for managing Linux hosts.   You can check out my project and follow my progress on my blog, also feel free to reach out to me on LinkedIn.   https://danielbostock.com/2019/12/24/ansible-project-deploy-a-new-network-network-security-policies/   ... View more

@DanielQueiroz - Can you please confirm if your MX is managing the corporate network as well, IE: Does 192.168.20.1 IP address exist on the MX or another network device?   Also if you can please let me know if you have specific Firewall rules configured on your MX to control inbound and outbound access.   This will help me to get a clearer picture of how packets will move from your vpn subnet to your corporate subnet.   With regards to the the reverse working, this is an indicator that there is not a routing issue but most likely a firewall issue or something similar that is seeing this traffic destined for this subnet and doing something to control it. If there was no connectivity you would not be able to reach from the corporate network. So, you are getting that far at least and good job, almost there now!   Thanks,.   Thanks, Daniel. ... View more

Paul, Just to be clear, can you confirm please if the server in question is on the VPN subnet or another subnet?   Thanks, Daniel. ... View more