This post is more than 5 years old
1 Rookie
•
117 Posts
0
66112
PowerConnect 6200 ACLs dont seem to work
Hello,
I have a total of four 6248s two groups at different locations that are setup with VRRP + OSPF. I tried to setup a simple ACL on one of the VLANs to permit some traffic, and block everything else, but I cannot get it to work. I have tried a lot of combinations trying to get this working, but so far no luck. Its just a simple ACL that should allow web/http traffic to the server 10.1.30.100, and block everything else.
The only type of ACE that seems to work are either a "deny ip any any" or "permit ip any any" if you try an ACE with a host destination and subnet mask 0.0.0.0 it just blocks everything. Has anyone else has been having ACL problems or is it just my incompetance thats preventing me from getting the 6200 ACLs to work properly? I didnt have this problem getting the ACL to work on our Cisco 2811 routers just when I tried on the PC6248s.
- config
- int vlan 720
- no ip access-group vlan720-in in
- exit
- no access-list vlan720-in
- access-list vlan720-in permit tcp any 10.1.30.100 0.0.0.0 eq 80
- int vlan 720
- ip access-group vlan720-in in
- exit
- exit
- copy run start
- y
JustinY
1 Rookie
1 Rookie
•
117 Posts
1
June 30th, 2010 22:00
Just an update on this issue. I have been working with Dell to identify why the ACL does not seem to be working. We discovered that the 6200 applies ACLs to traffic like a Cisco ACL VLAN Map as opposed to an input router ACL. This causes the ACL to be applied to not just routed or forwarded traffic but also to switched traffic within the same VLAN.
This has been the souce of my issues as my traffic is not confined to a single 6200. I developed a simple lab to verify that the 6200 was applying the ACL to switched traffic within the same VLAN.
First the 6200 has an ACL applied to VLAN5 both PC1 and PC2 are in VLAN 5. They are both on the same subnet 192.168.5.0/24. The ACL has a "permit icmp any any" statement but nothing else. Both PC1 and PC2 are running Windows XP Pro with IIS installed for testing. The firewall on both is disabled.
PC#1 IP: 192.168.5.2/24
PC#2 IP: 192.168.5.3/24
[6200]
| |
| |
| [2950T#2]<-->[PC#2]
|
|
[2950T#1]<-->[PC#1]
In this scenario PC1 and PC2 can ping each other without issue due to the permit icmp any any statement however you cannot access the IIS site on each of the other PCs.
Dell states that this is normal and if you want VLAN to VLAN communication you need to "permit ip " for this to work correctly. I also found that on return traffic from other VLANs was also being denied due to the ACL being applied on all inbound traffic. As a workaround the permit statement needed to be included for ALL traffic returning to the restricted subnet from other subnets. So in this case "permit ip any ".
I find this somewhat annoying that ACLs are applied as VLAN maps not as true inbound router ACLs like they are on similar Cisco devices such as the 3750. So there is a workaround. I hope they can address the issue in a future firmware update because I really think that the 6200 is a great device.
You can see here the difference between VLAN ACL Maps and input router ACLs where they are applied in relation to local VLAN traffic.
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swacl.html#wp1572522
bh1633
909 Posts
0
January 28th, 2010 18:00
Check out this whitepaper:
http://www.dell.com/downloads/global/products/pwcnt/en/pwcnt_IP_ACLs.pdf
JustinY
1 Rookie
1 Rookie
•
117 Posts
0
February 2nd, 2010 11:00
I have read that document already.
Are you saying there is something wrong with my ACL that I am not seeing? The thing is if an ACL is configured it blocks ALL traffic. Permit ACEs have no effect on the ACL it still just blocks ALL traffic. So if there is nothing wrong with my test ACL I posted then there is a problem with ACLs in general, and not specifically my ACL.
I am going to update to the latest production firmware, and try this again. If it works then I can safely say that ACLs truly are broken in the firmware I am running.
JustinY
1 Rookie
1 Rookie
•
117 Posts
0
February 4th, 2010 16:00
I updated the firmware to 2.2.0.3, but it did not help any. I have been trying a bunch of ACEs to see what works, and what does not. Here are a few that I have tried. Most of these don't work for whatever reason. Support isnt much help because officially "Dell does not support configuring ACLs" that also means if the ACL code is broken, and does not work they wont help you figure it out either. Maybe I am just losing it, but I thought all ACLs were pretty similar 1. choose the action permit/deny 2. define the protocol icmp/ip/udp/tcp.... 3. define the source ip and port if any. 4. define the destination ip and port if any.
Maybe there is a problem with using ACLs if your using VRRP, or OSPF? Anyone else have any trouble getting ACLs working with your 62xx?
THESE DID NOT WORK.
allow all IP traffic from any host to the network 10.1.30.0/24. DENIED
access-list vlan720-in permit ip 0.0.0.0 255.255.255.255 10.1.30.0 0.0.0.255
allow DHCP requests from any host over port 68 to any host on port 67. DENIED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 eq 68 0.0.0.0 255.255.255.255 eq 67
allow DHCP requests from any host over port 68 to broadcast on port 67. DENIED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 eq 68 255.255.255.255 0.0.0.0 eq 67
allow all UDP traffic from any host to broadcast on port 67. DENIED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0 eq 67
allow all UDP traffic from any host to the host 10.1.30.15 on port 53. DENIED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 10.1.30.15 0.0.0.0 eq 53
allow all UDP traffic from any host to any host on port 53. DENIED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 53
allow all TCP traffic from any host to the host 10.1.30.100 on port 80. DENIED
access-list vlan720-in permit tcp 0.0.0.0 255.255.255.255 10.1.30.100 0.0.0.0 eq 80
THESE WORKED.
allow ICMP from any host to any host. PERMITTED
access-list vlan720-in permit icmp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
allow udp from any host to any host on port 67. PERMITTED
access-list vlan720-in permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 67
speedcolo
43 Posts
0
February 22nd, 2010 10:00
One note from the techpub http://www.dell.com/downloads/global/products/pwcnt/en/pwcnt_IP_ACLs.pdf :
"On a PowerConnect 62xx switch, traffic that enters a VLAN interface via an internal source will be overlooked by an ingress ACL. This includes traffic originating from the switch interface and traffic that has been routed from another VLAN. Similarly, traffic exiting one VLAN interface only to enter another interface within the switch is also overlooked, as only traffic exiting the switch has ACLs applied to it."
I get the feeling that Vlan ingress ACLs really only apply to traffic entering "access" ports belonging to that vlan. In other words, it's a macro which appends the Vlan ACL to the per-port ACL (if any).
Past discussion on this issue includes:
http://www.dellcommunity.com/supportforums/board/message?board.id=pc_managed&thread.id=10925
http://www.dellcommunity.com/supportforums/board/message?board.id=pc_managed&thread.id=10859
http://www.dellcommunity.com/supportforums/board/message?board.id=pc_managed&thread.id=10466
Schmous
9 Posts
1
April 5th, 2012 12:00
We are experiencing the exact same issue on the 7200 series. access-group in or out doesn't filter anything! Quite frustrating! If anyone from Dell or other wise has an answer... it would be greatly appreciated, We could be enlightened.
Schmous.
DELL-Willy M
802 Posts
0
April 5th, 2012 16:00
Are you saying that you are not able to get your access list to function at all? Is the solution that JustinY provided not working in your situation? Here is an example of setting up an IP ACL on the 7200 series switch.
Configuring an IP ACL
The commands in this example set up an IP ACL that permits hosts in the
192.168.77.0/24 subnet to send TCP and UDP traffic only to the host with an
IP address of 192.168.77.50. The ACL is applied to port 2 on the
PowerConnect switch.
Configuring Access Control Lists
To configure the switch:
1 Create an ACL named list1 and configures a rule for the ACL that permits
packets carrying TCP traffic that matches the specified Source IP address
(192.168.77.0/24), and sends these packets to the specified Destination IP
address (192.168.77.50).
console#config
console(config)#access-list list1 permit tcp 192.168.77.0 0.0.0.255 192.168.77.50 0.0.0.0
2 Define the rule to set similar conditions for UDP traffic as for TCP traffic.
console(config)#access-list list1 permit udp 192.168.77.0 0.0.0.255 192.168.77.3 0.0.0.255
console(config)#exit
3 Apply the rule to inbound (ingress) traffic on Gigabit Ethernet Port 2.
Only traffic matching the criteria will be accepted on this port.
console(config)#interface gi1/0/2
console(config-if-Gi1/0/2)#ip access-group list1 in
console(config-if-Gi11/0/2)#exit
Schmous
9 Posts
0
April 5th, 2012 19:00
Willy
The example here is for a physical interface. I don't want to be critical over details... however I need to be
. Will this work on a IP VLAN interface more specifically, will this also work on a VRRP setup of those vlan interfaces?
Again thank you for your time.
Schmous
Schmous
9 Posts
0
April 5th, 2012 19:00
Sorry for the late response, and I appreciate the quick one in return.
I had to get some sleep after working through the night on this... and only did a preliminary search and quite frankly was so relieved to find someone else having this issue that I prematurely commented without looking for any follow up posts'.. Just wanted sleep! My apologies. I was just simply relieved after finding this as a known "issue".
This however was exactly what I was experiencing. DHCP didn't work... well didn't complete the negotiation, even with bootp enable globally and IP -helper on all L3 interfaces.. , traffic would flow. I thought there was a bridge in this network somewhere to be honest.
It is a client site and I am building out from existing to the new network. It has posed some interesting challenges, this one was no exception. The vendor of preference was Dell for obvious reason. $$$ What I don't understand however is why deviate from industry standard concepts. I know they are Ciscoesque concepts. However...
Thank you very much Willy. I know where to go form here....
Schmous.
DELL-Willy M
802 Posts
1
April 6th, 2012 10:00
The 7000 series switches allow an ACL to be applied on ingress and egress of an interface and can be applied globally (If an ACL is applied globally on a Broadcom-based PowerConnect switch, it will be applied to all interfaces.) or per interface.
Based on my research this should allow you to apply the ACL to a VLAN interface along with the VRRP.
IP-based ACLs can be activated on Broadcom-based PowerConnect switches using the following syntax from either Global or Interface Configuration mode.
• ip access-group { name } [ in | out ] [ sequence ]
Use the no form of the command to deactivate the ACL.
• no ip access-group { name } [ in | out ] [ sequence ]
Please keep us updated
Schmous
9 Posts
0
April 24th, 2012 16:00
Willy
Well I am still banging my head on this one. I have created the ACL below. I would like to harden it further, however one step at a time.
I have broken out the vlan assignments based on the third octet. So vlan 70 has a L3 interface VLAN70. Its IP is 10.1.70.1/24. All other vlans are broken out this way. I am trying to only allow 3 devices into the vlan and allow the subnet out. All other subnets should not be able to get through. All vlans will have access to the cloud via the ASA.
I am using ICMP to test. It gets through no matter what I try.
The physical layout is a hub and spoke with vlans trunked out to the access layer. All are 10gig uplinks. The test PCs are on different access switches going through the core with the ACLs applied to each l3 interface. VRRP will be added after I get the security correct.
[ASA5520]
|
|
[7024]<-->[All l3 gateways are here for each vlan with IP-Helper enabled as well as all ACLs]
| |
| |
| |
| [6248]<-->[PC on VLANxx]
|
|
[6248]<-->[PC on VLAN70]
enable
configure
interface VLAN70
no ip access-group VLAN70_IN in
exit
no access-list VLAN70_IN
access-list VLAN70_IN permit ip 10.1.70.0 0.0.0.255 any
access-list VLAN70_IN permit ip 10.1.1.30 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 10.1.1.40 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 10.1.1.60 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 192.168.1.20 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN deny ip 10.1.0.0 0.0.255.255 any log
access-list VLAN70_IN permit ip any any >>> I added this as I dont think this device does any xlate for return traffic. If it is not needed please let me know. It is not secure from my perspective like this<<
interface VLAN70
ip access-group VLAN70_IN in
exit
exit
I can ping from other vlans to devices on this segment. I have not added either permit or deny for ICMP so it is confusing to say the least. I know there is an implied deny any any at the end. I added the deny line to log attempts to syslog from internal vlans for auditing purposes. The implied deny should block icmp no? I am also reading that the egress filter only works on physical interfaces. So a logical l3 interface won't acl traffic out. Which might help me in this situation.
any help would be greatly appreciated.
schmous
DELL-Willy M
802 Posts
0
April 24th, 2012 18:00
Schmous,
• access-list VLAN70_IN permit ip 10.1.70.0 0.0.0.255 any
access-list VLAN70_IN permit ip 10.1.1.30 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 10.1.1.40 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 10.1.1.60 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN permit ip 192.168.1.20 0.0.0.0 10.1.70.0 0.0.0.255
access-list VLAN70_IN deny ip 10.1.0.0 0.0.255.255 any log
access-list VLAN70_IN permit ip any any
Your access-list is only denying the 10.1.0.0 network. The permit ip any any leaves the door wide open.
1. Your access-list is only denying the 10.1.0.0 network. The permit ip any any leaves the door wide open. When packets hit the interface with the access-list it starts at the top of the list to match the statement on each line. So when any ip hits the line “permit ip any any” it allows everything thru the port and never reaches the implied deny any any and the end of the list.
2. With this statement “permit ip 10.1.1.30 0.0.0.0 10.1.70.0 0.0.0.255” you are permitting the exact address 10.1.1.30 to the 10.1.70.0 network. Is this what you are intending? If you are wanting to permit a subnet/network then you would need to adjust the wildcard mask.
3. Yes, the ACL can only be applied ingress on a VLAN interface.
4. What switch are you applying the ACL’s to? We need to look at where they are placed in the network topology.
Can you run these show commands and report your output?
console#show ip access-lists
Current number of ACLs: 1 Maximum number of ACLs: 100
ACL Name Rules Interface(s) Direction
------------------------------- ----- ------------------------- ---------
alpha 3 1/g1 Inbound
console#show ip access-lists alpha
IP ACL Name: alpha
Inbound Interface(s):
1/g1
Rule Number: 1
Action......................................... deny
Match All...................................... FALSE
Protocol....................................... 6(tcp)
Source IP Address.............................. 172.16.1.6
Source IP Mask................................. 0.0.0.0
Destination IP Address......................... 0.0.0.0
Destination IP Mask............................ 255.255.255.255
Destination L4 Port Keyword.................... 23(telnet)
Rule Number: 2
Action......................................... deny
Match All...................................... FALSE
Protocol....................................... 6(tcp)
Source IP Address.............................. 172.16.1.6
Source IP Mask................................. 0.0.0.0
Destination IP Address......................... 0.0.0.0
Destination IP Mask............................ 255.255.255.255
Destination L4 Port Keyword.................... 80(www/http)
Rule Number: 3
Action......................................... permit
Match All...................................... TRUE
Schmous
9 Posts
0
April 24th, 2012 19:00
Willy
This device is a 7024. All layer 3 interface reside here. If you consult my meager drawing in my last post. All ACLs are on the core. IE this PowerConnect 7024.
Based on what you said it is not a best fit like a Cisco ACL. It goes through the entire ACL. before it actions the data. So the deny 10.1.0.0 line is not stopping the traffic sourced from there. I have tried with or without the permit any any at the bottom of the ACL. The result is icmp responds. So I am not sure what to say about this....
I am currently locked out of both the console and telnet sessions. This happens often and a reboot is needed. We applied a new code last week that was suppose to fix this bug. Apparently it has not. I cannot reboot the device till everyone has gone home. Around 10pm PST. Ill post what you need then, if not tomorrow.
If you would like we can take this discussion to email, I can send you actual configs, diagrams etc so you can get a better understanding of what I am doing. I will say it is a pretty standard setup. Core device does all routing and ACLs. Default gateway is the Firewall. All desktop/printers are off of the access layer devices which connect via trunks to the core. There will be about 30 vlans with about 10-15 lines per acl. I only have one vlan currently configured with an ACL. The one previously posted. This shouldn't tax this box by any stretch.
Thank you again for your time.
schmous
Schmous
9 Posts
0
April 24th, 2012 19:00
Oh and yes the single source to network access-list is intended. 4 host essentially are allowed into the subnet.
S.
DELL-Willy M
802 Posts
0
April 25th, 2012 17:00
I agree mail would be a better media for communication.
William_Marsh@Dell.com