Prevent inter-VLAN routing on MX

[PentagonSystems]

I am trying to use a MX64 as the 'core' router on my lab network.  I have 2 VLANS which are all /24s that follow the addressing 10.1.1.0/24 for vlan 1, 10.2.2.0 for vlan 2. for this example

I would expect to have to set up routing between 10.1.1.1 and 10.2.2.1, however the MX allows routing between vlans by default.  This in itself is not a problem, and I attribute it to the default layer3 firewall rule to allow any any.  Therefore, I created a policy to prevent routing from 10.1.1.0/24 from routing anything in the 10.0.0.0/8 private address space.  This did not work, so I suspected that this may be in logical conflict because 10.1.1.0/24 itself is within the subnet mask of the rule, however when i changed the rule to prevent 10.1.1.0/24 from routing to 10.2.2.0/24 specifically I can still ping from any 10.1.1.0/24 machine to the gateway 10.2.2.1

My rule is as follows

policy = deny

proto = tcp

source = 10.1.1.0/24

src prt = any

destination = 10.2.2.0/24

dst prt = any

comment = no inter vlan

Can someone help me understand what i'm doing wrong?

[PentagonSystems]

update:  it actually appears to prevent ping to a host on the 10.2.2.0/24 network (for example 10.2.2.10), but the gateway (MX) replies.  This isn't ideal, but i understand why it's happening. Ideally I would like the MX to only reply with the address that is facing the host (for example 10.1.1.1 but not 10.2.2.1).  I wouldn't even want a host I'm trying to isolate to be aware of how many vlans my MX services, which I dont seem to be able to prevent.

The only thing i can think of to close this gap is to configure the MX to not respond to ICMP at all for that VLAN.  I suppose this will be fine unless some utility needs to do a status check on the gateway and uses ICMP.  Does anyone have any other ideas?

[MilesMeraki]

I just replicated this issue. I also attempted to create firewall rules to block connectivity - No Luck. I attempted to create a group policy specifying a custom firewall rule to block ICMP to the default gateway of the second VLAN and still no luck.

I'd suggest calling Meraki support to ensure this isn't a bug or it is indeed something that is intended by design.

[PhilipDAth]

I tried this with the beta firmware 13.22 and it did the same thing as well (allow ping traffic to the MX interface).

[lpopejoy]

Yes, this has always been an issue. I've always ignored it, but wish it would be fixed as well!

[ElliotGardner]

Ping traffic is not TCP so your pings won't be blocked.  You either need to block all or block ICMP (which is ping traffic).  See below.  If you wanted to block both ways, you would need to add another rule with source and destination flip flopped.

[BHC_RESORTS]

---

@ElliotGardner wrote:

Ping traffic is not TCP so your pings won't be blocked.  You either need to block all or block ICMP (which is ping traffic).  See below.  If you wanted to block both ways, you would need to add another rule with source and destination flip flopped.

---

This here. Blocking ICMP is what you want. We block some inter-vlan routes, and our rules work without issue on the latest beta firmware.

[Paulofg]

Also keep in mind that any existing flows (e.g. if you are pinging the same source/destination) will be not be blocked immediately.

Create the rule, stop the ping, wait 15 minutes (probably less) then test it.

If it's a lab environment, simply reboot the MX to clear all existing flows once the rule has been added.

[Kave]

The problem is VPN, Because Meraki MX made Auto VPN, all subnet still can see each other, go to SITE TO SITE VPN and make rule there as well.