How to segregate VLANS

Solved
TimBisel
Getting noticed

How to segregate VLANS

I cant seem to segregate vlan traffic. The automatic routing in the MX is throwing me for a loop. I need n internal VLAN that is blocked from all other VLANs. I added in what I think the firewall rules should be but can not get it segregated. wireless is easy as I can just not make it part of LAN, but this will be a physically connected network inside one of my locations I need to . We have Symantec AV so I cant ping endpoints because pings are blocked, but I can still reach the MX ip of every VLAN regardless of what VLAN I am connected to. Any help is appreciated.

 

 Capture.JPG

1 Accepted Solution
PhilipDAth
Kind of a big deal
Kind of a big deal

I would create a new group policy, say "V:LAN10" (or whatever).  Apply it to the VLAN interface of the MX you want to limit.

 

In that group policy create firewall rules to deny access to the other subnets.  Personally, I would just deny all RFC1918 address space.

Deny all to 192.168.0.0/16

Deny all to 10.0.0.0/8

Deny all to 172.16.0.0/12

View solution in original post

9 Replies 9
NolanHerring
Kind of a big deal

Your rules look accurate. Can you still reach devices between them?

I believe however that you will be able to ping the MX, but just not get passed it.
Nolan Herring | nolanwifi.com
TwitterLinkedIn
TimBisel
Getting noticed

Do to our AV I cant test pinging devices because ICMP traffic to them are blocked so even if I could reach them it says I cant. But the gateway IP's would still fall under that rule so I don't understand why traffic is still making it through. I don't have L3 Switching enabled on switch but just to take that out of equation I am plugged straight into the MX. 

TimBisel
Getting noticed

Ok, you are right so far, but two things.

 

1.What am I missing on why the MX is still reachable?

 

2. I have my VLAN 90 blocked from seeing the other local VLANS, But I have ~30 locations that are going to be connecting back via VPN. And I going to need to add each of the VLANs to this firewall rule? This is going to become very hard to manage going forward is so.

WadeAlsup
A model citizen

Site-to-site VPN has settings to choose which local networks participate in the site-to-site vpn. It also has it's own inbound and outbound firewall settings that can be configured there.

Found this helpful? Give me some Kudos! (click on the little up-arrow below) and If my reply solved your issue, please mark it as a solution 🙂
RichG
Getting noticed


@TimBisel wrote:

Ok, you are right so far, but two things.

 

1.What am I missing on why the MX is still reachable?

 

I believe this is because the connections to the MX are handled by the "input" firewall rules and the traffic to devices in the other VLAN are handled by the "forward" firewall rules.  Many firewall devices have two separate sets of rules, one for traffic destined for the device (input) and one destined for devices on the other side (forward).  Because the pings that are destined for the MX itself, the packets never go through the "forward" rules, even if they are for a different interface than the one they come in on.

 

 

  In the case of the Meraki, the "input" rules seem to be governed by the "Security appliance services" rules for the outside interface and things like the "Local device status page" for the inside interfaces.

 

PhilipDAth
Kind of a big deal
Kind of a big deal

I would create a new group policy, say "V:LAN10" (or whatever).  Apply it to the VLAN interface of the MX you want to limit.

 

In that group policy create firewall rules to deny access to the other subnets.  Personally, I would just deny all RFC1918 address space.

Deny all to 192.168.0.0/16

Deny all to 10.0.0.0/8

Deny all to 172.16.0.0/12

TimBisel
Getting noticed

That is actually what I was going to move to after thinking about it more. I think Meraki needs a "Experienced" mode that does less of this Apple style "We know what you want better than you" stuff and turn off some of these automatic things so we don't need to have work around for turning off some of the "simplicity" features.

RichG
Getting noticed


@TimBisel wrote:

That is actually what I was going to move to after thinking about it more. I think Meraki needs a "Experienced" mode that does less of this Apple style "We know what you want better than you" stuff and turn off some of these automatic things so we don't need to have work around for turning off some of the "simplicity" features.


I think the desire for "Experienced" mode ranks right up there with IPv6 and NoNAT on the desired feature list.

Adoos
Building a reputation

@TimBisel  Just curious are you using Meraki where you have a control/plant network? 

Get notified when there are additional replies to this discussion.