Layer 3 Firewall in Group Policy settings

getnyce32
Conversationalist

Layer 3 Firewall in Group Policy settings

I have a need to have L3 firewall settings at the group policy level.  I'm curious if i'm able to use the "Local Lan" as a destination in Group Policy the same way it is using in the "Firewall" section of an SSID.  And if so will it implicitly allow DNS and DHCP through?  

 

 

7 REPLIES 7
NolanHerring
Kind of a big deal

The group-policy will override any of your firewall settings on MR or MX devices, so keep that in mind. The allow/deny LOCAL LAN on the wireless firewall rules isn't an option on the Group Policy method, so if you want to say 'block local lan access' then you need to create 3 rules to deny RFC1918. I'm pretty sure DNS/DHCP is inherently allowed but might be a good idea to test. Can you show an example of how your trying to setup your rules?
Nolan Herring | nolanwifi.com
TwitterLinkedIn

Here is the most efficient way I can think of writing the policy.

 

asdfsadfa.png

I'm assuming the first 6 rules are for internal IP correct?

So client joins, say gets 172.16.0.10 for his IP on a 172.16.0.0/24 network (example). Everything will work for him, DNS/DHCP etc. He just won't be able to go to anything internal after that, like another subnet on 172 etc. He'll be able to reach his gateway and all that though.

I have a group policy setup for company owned iPads. No apple devices can get apple updates, but when I move an iPad over into the group policy, they can get updates (because i'm allowing it), however I am blocking all RFC1918. They still connect just fine and have no issues with DHCP/DNS.

So I don't think you need to specifically allow DNS/DHCP.
Nolan Herring | nolanwifi.com
TwitterLinkedIn

Actually let me put in a correction here. I was assuming your DHCP/DNS is the MX appliance (assuming you have one?). If it is then I don't think you need to do anything as I don't in my example.

If your DNS/DHCP is an external server (windows server for example), then I believe you will have to have those rules.
Nolan Herring | nolanwifi.com
TwitterLinkedIn

Thanks for the input.

 

This group policy is to be used in conjuction with 802.1x, specifically the role being passed by the aruba clearpass server will dictate which group policy the user gets.  So if a user has been given a role as employee and user will be giving the group policy of employee and will have access to everything. If the user is being given the policy of guest it will only have access to the internet. 

 

My policy is working I was just trying to figure out a way of making it shorter. 

 

Just an FYI.  In your example you give below i'm finding that if a client joins and gets 172.16.0.10 it WILL NOT be able to access anything else in that same subnet.  For instance that client will be able to get out to the internet but it will not be able to ping it's default gateway of 172.16.0.1 or any other client on that network. 

 

Thanks again for your help. 

 

EDIT:  My device is just an AP using Bridge mode for the SSIDs


Just an FYI.  In your example you give below i'm finding that if a client joins and gets 172.16.0.10 it WILL NOT be able to access anything else in that same subnet.  For instance that client will be able to get out to the internet but it will not be able to ping it's default gateway of 172.16.0.1 or any other client on that network. 

 


Sorry I may not have been clear on this. Yes that is accurate. However something I have noticed (at least strictly on the Meraki side) is if you do not have L2 LAN Isolation (bridge-mode only) then you can do L2 discoveries on that network, see other clients etc. You won't be able to talk to them but just something to keep in mind. When I enable the L2 LAN Isolation, do a scan, I only see myself and the gateway.

Nolan Herring | nolanwifi.com
TwitterLinkedIn

Don't forget that DNS requires UDP and TCP on port 53.  UDP is used for small queries and TCP is used for large replies.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels