cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5383
Views
0
Helpful
10
Replies

Understanding SG500 IP ACLS?

jamesrusso
Level 1
Level 1

Hello, 

I am updating this question because I have reconfigured things. I am attempting to setup two SG500-52P switches in a small office with the following scenario:

VLAN 1 - 10.1.0.0/24 - Management

​VLAN 5 - 10.5.0.0/24 - Network Gear (sonicwall TZ210 is @ 10.5.0.1 with routes setup back to 10.5.0.254 which is VLAN interface on SG500)

VLAN 10 - 10.10.0.0/24 - Computers/Printers

VLAN 20 - 10.20.0.0/24 - Video Players

VLAN 30 - 10.30.0.0/24 - Voice

VLAN 40 - 10.40.0.0/24 - Cameras

VLAN 50 - 10.50.0.0/24 - Guest (Should have no access to other VLANS, outside access only).

My DHCP server is @ 10.10.0.15. I have DHCP Helper setup for all the necessary VLANs. DHCP is working fine for all the VLANs. All VLANs can access internet and each other.

I have some wireless access points which provide access to both VLAN 10 and VLAN 50 via different SSIDs. These physical ports are setup tagged on 10 and 50, with their default interface being VLAN 1 (Management LAN).

My final step in this is to secure all our production VLANs (1,10,20,30,40) from our Guest VLAN (5). VLAN 50 should *only* be able to get to the internet. Can someone help me with the ACLs which would be required for this? I've read a bunch of stuff, tried a million combinations over the last two days and cannot seem to get it to work. I will also need a hole poked in these ACLs to allow VLAN 50 access to DHCP.

When adding the ACLS, I enable logging and the entries in the log make no sense to me with the source and destination IPs. They seem to be reversed. I would think adding a ACL to VLAN 10 with a destination of 10.10.0.0/24 and source of 10.50.0.0/24 with a deny would result in a denial, but it isn't working for some reason. I can also confirm that I am using the 0.0.0.255 wildcard netmask correctly (vs 255.255.255.0). 

The other option I am considering is just trunk VLAN 50 to the router and setup a VLAN interface on it and bypass the routing on the switch all together. Perhaps this is my best option because it will keep ACLs off the SG500 and the Guest VLAN is supposed to be "just on the internet anyways"...

Thanks for reading..

-jr

 

 

1 Accepted Solution

Accepted Solutions

jbattist
Level 1
Level 1

James,

      I have set this up in the lab, using the web interface of the switch, and have isolated the guest VLAN from the rest of the networks by creating an IPv4-based ACL.  Then under IPv4-based ACE, I added a deny statement from the guest VLAN network to one of the other VLAN networks for IP(any).  I repeated this process for each of the other VLAN networks.  I then put a permit any any on the bottom of the list.  Then I applied the ACL to the VLAN under ACL Binding (VLAN).  I could have omitted the permit any any if I choose the default action of the binding to be "permit any".  But I included it in the ACL list.  Anyway,  after applying the binding, from a PC in the guest network, I could not ping any of the other networks, but could ping 4.2.2.2 and was able to access the Internet.  From the other networks, I could not ping this guest PC.   I could ping both ways before the ACL was applied to the VLAN.   So all I really did was verify Aleksandra suggestion, but applied the ACL to the VLAN itself, and not the ports.  Hope this is helpful.

 

James

View solution in original post

10 Replies 10

V K Moorthy
Level 1
Level 1

Hi,

 

Using ACL you can allow http,https,ftp services with source IP as VLAN 50 and deny rest all traffic with source IP as VLAN 50,Apply this ACL in interface VLAN 50.

 

 

regards

Moorthy

So, that would prevent packets from coming into VLAN 50 since they are checked on ingress, correct?

So, you think the ACLs would be: 

Source -> Dest

Permit 10.50.0.0 0.0.0.255  -> Anywhere http

Permit 10.50.0.0 0.0.0.255 -> Anywhere https

Deny any any

I will give it a try and report back...

 

 

 

I have done as you suggested, but this will still allow traffic to our internal VLANs on those ports. I need to secure these internal VLANs from traffic originating from VLAN 50. Right now, I can still get to port 80 on 10.30.0.10 which is our PBX..

Since these are done in ingress, I would think I would simply add them to the other VLANs and protect the other VLANs from VLAN 50, rather then applying them to VLAN 50.

Here is the listing... I would really prefer to not have to define access to everything in this ACL.  Sitting here watching the logs I'm finding more and more the public would need access to.  Just seems like it will be too difficult to manage...

Extended IP access list VLAN_50
    permit  udp any any any bootps ace-priority 10
    deny    ip 10.50.0.0 0.0.0.255 10.30.0.0 0.0.0.255 ace-priority 20 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.20.0.0 0.0.0.255 ace-priority 30 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.40.0.0 0.0.0.255 ace-priority 40 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.10.0.0 0.0.0.255 ace-priority 50 log-input
    permit  tcp 10.50.0.0 0.0.0.255 any any www ace-priority 60
    permit  tcp 10.50.0.0 0.0.0.255 any any 2195 ace-priority 70
    permit  tcp 10.50.0.0 0.0.0.255 any any 5222 ace-priority 80
    permit  tcp 10.50.0.0 0.0.0.255 any any 5223 ace-priority 90
    permit  tcp 10.50.0.0 0.0.0.255 any any 5353 ace-priority 100
    permit  udp 10.50.0.0 0.0.0.255 any any domain ace-priority 110
    permit  tcp 10.50.0.0 0.0.0.255 any any 443 ace-priority 120
    deny    ip any any ace-priority 2147483647 log-input

 

thanks,

-jr

 

I am thinking you don't need an ACL at all. If you have 2 major aggregate connections then you may set those as protected port.

 

Example:

 

Port 1 of switch = All your production stuff that needs to communicate to one another and all that stuff works as it is

 

Port 2 of switch = AP that services as an aggregate connection for all of your guest internet user

 

With protected port enable on each other, port 1 and 2 cannot communicate to each other, period. It will communicate to upstream and that is all.

 

May give this a try and see if it yields a result you want. You can find the configuration for protected port under "port management" setting

 

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

Tom, 

Thanks for commenting. I've read lots of your other posts on here. Right now we have the following 

Port 1 Upstream to Sonic wall on 10.5.0.0/24 subnet. Sonicwall is 10.50.0.1

Port 2 and Port 24 ports to Access Points. This has untagged Vlan 1 (mgmt), and tagged VLAN 10 (Production) and tagged VLAN 50 (Guest).

All other ports are devices on various VLANS.. Some CCTV, Some Phones, Some Production Computers, etc. 

So, which ports would need to be protected?

thanks,

 

-jr

 

Hi James,

Tom has really good idea but it is possible only on ports where is only one vlan present (access port) and no trunk.

Your Guest users need to access internet only. If so there destination IP in their packets should never have any IP from other VLANs but public IP.

So you could possibly specify ACL such as:

deny ip 10.50.0.0 0.0.0.255 10.0.0.0 0.255.255.255
permit any any

and assign to port 2 and 24.

Any IP traffic generated by guest user would be dropped if the destination IP is local.

Remember that even when guests would need to connect to router (switch) and Sonicwall as the default gateway they would use MAC address in the destination but IP of public site would remain unchanged.

Regards,

Aleksandra

 

jbattist
Level 1
Level 1

James,

      I have set this up in the lab, using the web interface of the switch, and have isolated the guest VLAN from the rest of the networks by creating an IPv4-based ACL.  Then under IPv4-based ACE, I added a deny statement from the guest VLAN network to one of the other VLAN networks for IP(any).  I repeated this process for each of the other VLAN networks.  I then put a permit any any on the bottom of the list.  Then I applied the ACL to the VLAN under ACL Binding (VLAN).  I could have omitted the permit any any if I choose the default action of the binding to be "permit any".  But I included it in the ACL list.  Anyway,  after applying the binding, from a PC in the guest network, I could not ping any of the other networks, but could ping 4.2.2.2 and was able to access the Internet.  From the other networks, I could not ping this guest PC.   I could ping both ways before the ACL was applied to the VLAN.   So all I really did was verify Aleksandra suggestion, but applied the ACL to the VLAN itself, and not the ports.  Hope this is helpful.

 

James

James, 

 

Thank you so much for taking the time to set this up in the lab. I think you are likely on the right track and I will try and configure this later this evening and report back my findings. 

Can someone just explain when the ACLs are actually evaluated? The documentation say ingress, so that would be packets arriving on the VLANs?

Ok, so I think this is working now, here is what I have setup with a default permit policy..

Extended IP access list VLAN_50 

    permit  udp any any any bootps ace-priority 10
    deny    ip 10.50.0.0 0.0.0.255 10.10.0.0 0.0.0.255 ace-priority 20 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.20.0.0 0.0.0.255 ace-priority 30 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.30.0.0 0.0.0.255 ace-priority 40 log-input
    deny    ip 10.50.0.0 0.0.0.255 10.40.0.0 0.0.0.255 ace-priority 50 log-input

 

switch88fbe4#show interfaces access-lists

Interface                  ACLs     

---------          -----------------------

vlan 50            Ingress: VLAN_50    

 

and it seems to be working well! Thanks for all your help!

Glad it worked James.  Thanks for using the support forum also.  Have a great day.

 

James