MX Deny inter-VLAN routing

[ToryDav]

Good Day,

Looking for a recommendation to deny inter-vlan routing on the MX using Layer 3 firewall rules. In this case I created a rule denying all RFC1918 subnets in source and destination, and put that above the default allow rule. 

This way outbound to the internet is not bothered, and I can create specific allow rules to permit some inter-vlan routing where applicable.

Seemed to be working okay so far in testing, however I did notice some ICMP response not founds in a packet capture when ping testing two hosts in the same VLAN. I'd think that if they are in the same VLAN, the layer 3 rules would not apply, so I am troubleshooting the MX as a bug and changed firmware version to the latest patch.

Waiting to confirm if this resolved the issue, but can you sanity check me here?

[alemabrahao]

Sorry for the question, but why block ICMP between VLANs? Another question is, is the MX the network gateway? Because if it is not, in this case communication between hosts in the same VLAN will not pass through the firewall.

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

[ToryDav]

Hi alemabrahao, the requirement is to block all traffic between the VLANs, not just ICMP. I'm only using ping to do some basic testing in the rules.

MX is the gateway. I'm going to recreate the rules in my lab MX to see if the result is the same.

PREVIEW

[alemabrahao]

I see, in this case I suggest calling Meraki support.

[RaphaelL]

I don't understand : Seemed to be working okay so far in testing, however I did notice some ICMP response not founds in a packet capture when ping testing two hosts in the same VLAN. I'd think that if they are in the same VLAN, the layer 3 rules would not apply, so I am troubleshooting the MX as a bug and changed firmware version to the latest patch.

That's right. Intra-vlan will not be blocked by the L3 firewall. That is not a bug.

[alemabrahao]

So this is a serious flaw, this is the basics of a firewall.

In the past I remember that it was possible to carry out this configuration, if in fact the Meraki engineering team changed this, they should review the concepts.

I've been working with Palo Alto for the last few months and I'm loving it, I think it's the best firewall I've ever worked on in my life.

[RaphaelL]

Ugh ? What ?

How is this a flaw ?

[RaphaelL]

I think you are mixing Intra-vlan and Inter-vlan

[alemabrahao]

Nope, I'm sure what I'm talking about. I have already carried out several laboratories and implementations in the past.

[alemabrahao]

Yes, it is a flaw, in many cases communication between clients on the same network segment is not necessary. I repeat again, this is the basics expected of a decent firewall.

[RaphaelL]

Okay if you say so.

[ww]

I wanted to respond the same. But I think hes saying that ping traffic is blocked  between clients in the same vlan? ( Based on his packet capture) but its not clear if the ICMP response not found is even related  to this.  another thing missing here is if the clients are on different mx ports or 1 port trunked to a switch. I think there was bug at some point using different ports on a specific mx. But using a trunk to a switch and clients on that switch,  traffic should not even traverse the mx.

[ToryDav]

The clients are on a L2 switch. The switch is trunked to the firewall. I am setting up a lab to replicate the MX environment now and we will see if I see the same result of traffic being blocked where it should not be. It could be a switching issue.

More to come.

[alemabrahao]

In this case I have to agree with @RaphaelL , they are on the same segment L2 will not block anyway. Hey I thought the hosts were directly connected to the MX. In this case, you might be able to solve it with L2 ACL.

[alemabrahao]

Or configure Private VLANs depending on the switch model.

[RaphaelL]

Exactly.  Layer 2 communications ( intra-vlan )  can't be block by the Layer 3 firewall (inter-vlan ) of the MX. 

There ways to achieve that ( client isolation on a switch ? ). 

Client A on vlan 10 on switch 1 port 2 will reach Client B on vlan 10 on switch 1 port 3 without ever reaching the MX.

( I know you know that btw ) 

[GIdenJoe]

I'm also gonna post the same answer as some of my colleagues did.

The reason why you are getting response not found in captures is probably because some of the ICMP echo's are reaching the MX which shouldn't normally since intra-VLAN traffic does not pass the firewall since hosts will directly communicate to each other based on their source and destination MAC addresses.

The only few reasons I can think is that the client is perhaps using the MAC address of the MX as destination erroneously instead of the endpoint.  Or that the switch is flooding the frame to the MX also while the response is not being flooded.  Or that your endpoints are both directly on the LAN ports of the MX.

You would need to check the capture itself and really look at the source and destination mac addresses being used while having the endpoints mac addresses to check.

It is also important to know that switched traffic on an MX will not be treated as "forwarding" traffic and will not be subject to the L3/4 rules.  Only an MX in passthrough mode could have this but then you are using the WAN1 port and that traffic will be subject to the rules.

[ToryDav]

Thanks GldenJoe, the only issue I see with all this right now is I exported the, VLANs, Subnets, policy objects and the L3 rules and ported them over to a lab MX that I have setup to simulate the environment and all testing passed as expected.

Intra-VLAN traffic were permitted worked as expected.
Inter-VLAN traffic where permitted worked as expected. 
Traffic not specified explicitly to be allowed was not allowed. 
Internet bound traffic worked just fine.

However on the staged equipment where we noticed the issue, test hosts cannot ping each-other within the same VLAN, or in different VLANs that are explicitly permitted.

Changing firmware to the latest patch changed nothing.
Moving the hosts from the switches directly onto the MX changed nothing.

So I built SVIs on Stack 1 and Stack 2 to do ping testing to rule out the hosts themselves perhaps dropping the ping, and they work as expected.

At this point I am thinking this is a problem with some of these particular test laptops, but unsure otherwise.

[GIdenJoe · Accepted solution]

Yes by default you can never ping a windows host.  Usually in a test scenario I don't even bother with creating explicit rules in a windows machine, I just temporarily disable the windows firewall to be sure the network itself shows as being working as intended.

[ToryDav]

Same, but without access to them I needed to actually prove that was the issue. Just to update you all, this was related to windows firewall.