UNSOLVED

rmd1023

updated

22 years ago

R

rmd1023

5 Posts

0

17778

December 13th, 2004 20:00

access-lists on a 6204F?

I'm trying to set up access-lists on a 6204F. The access list is:

ip access-list "testacl"
permit-tcp 172.22.160.0 0.0.0.255 any 172.22.14.100 0.0.0.1 22
permit-tcp 172.22.160.0 0.0.0.255 any 172.22.14.100 0.0.0.1 10000
permit-tcp 172.22.160.0 0.0.0.255 any 172.22.14.100 0.0.0.1 5900
permit-tcp 172.22.4.0 0.0.1.255 any 172.22.14.100 0.0.0.1 22
permit-tcp 172.22.4.0 0.0.1.255 any 172.22.14.100 0.0.0.1 10000
permit-tcp 172.22.4.0 0.0.1.255 any 172.22.14.100 0.0.0.1 5900
permit-tcp 172.22.8.32 0.0.0.31 any 172.22.14.100 0.0.0.1 22
permit-tcp 172.22.8.32 0.0.0.31 any 172.22.14.100 0.0.0.1 10000
permit-tcp 172.22.8.32 0.0.0.31 any 172.22.14.100 0.0.0.1 5900
permit-tcp 172.25.127.92 0.0.0.0 any 172.22.14.100 0.0.0.1 22
deny tcp any 172.22.14.100 0.0.0.1
permit ip any any

this should permit TCP connections to the 172.22.14.100 and .101 machines from the specified ranges on ports 22, 10000, and 5900. all other TCP should be blocked from those two hosts. Other IP, such as UDP and ICMP, should be permitted.

When I apply the access list to an interface, it appears to block *all* traffic, including ICMP, to that network.

While it is a commendable level of security, it's really not what I want it to do.

Even better, I tried mapping the ACL from the web interface and ended up with the ACL mapped to two vlan interfaces and at that point, the switch rebooted.

Are access-lists just broken on the 6024? If not, what am I doing wrong, here?

Thanks!

Here's the text from the spurious reboot:
------------------------------------------------------------------------

ex09-Dec-2004 16:44:34 %GCLI-F-SORTINGFAIL: GCLIG_mib2cli_parse: Special sorting failed

***** FATAL ERROR *****
Reporting Task: STSA.
Software Version: 1.0.2.07 (date 21-Nov-2003 time 09:58:38)
0x7d764
0x7d784
0x7f294
0x3835a4
0x279f2c
0x27a3e0
0x27dfc8
0x36710c
0x36e53c
0x36f458
0x37b95c
0x35a074
0x3539f8
0x353c34
0x34b2dc
0x34ba50
0x34c1e4
0x34cb84
0x64bf4

Boot1 Checksum Test...............................PASS

Boot2 Checksum Test...............................PASS

Flash Image Validation Test.......................PASS

Testing CPU PCI Bus Device Configuration..........PASS

BOOT Version 1.0.0.13 Date 13-Aug-2003 Time 15:28:31


Autoboot in 2 seconds - press RETURN or Esc. to abort and enter prom.
Preparing to decompress...

Decompressing SW from image-1
cf9270
OK
Running from RAM...

*********************************************************************
*** Running SW Ver. 1.0.2.07 Date 21-Nov-2003 Time 09:58:38 ***
*********************************************************************

HW version is 00.01.64
Base Mac address is: xxxxxxxxxxxxx
Dram size is : 256M bytes
Dram first block size is : 235520K bytes
Dram first PTR is : 0x1800000
Dram second block size is : 1984K bytes
Dram second PTR is : 0xFE00000
Flash size is: 32M
Tuning File info. Ver: 1.0.0 Creation date: Oct 30 2003 07:39:14
PowerConnect 6024F
Tapi Version: v1.1a1-P18
Core Version: v1.1a1-P18
09-Dec-2004 16:45:07 %INIT-I-InitCompleted: Initialization task is completed
  • GregG1

    2 Intern

    •

    812 Posts

    163

    0

    Posted December 14th, 2004 13:00

    The implicit "deny any any any" at the end of the access-list is the culprit. You would need to modify your access-list to permit ICMP and UDP traffic.
     
    When you use the ACE "permit ip any any", you are only permitting traffic with a Layer 3 protocol number of 4. Other Layer 3 protocols like ICMP (protocol number 1) will not be permitted. Cisco modified their "permit ip any any" to allow for other common Layer 3 protocols. The equivalent of Cisco's "permit ip any any" on the 6024 would be "permit any any any".
     
    If you want to specifically permit UDP and ICMP traffic, you would need to include the ACEs "permit icmp any any" and "permit udp any any".  Another option, would be to configure the access-list to explicitly deny the unwanted traffic and use "permit any any any" at the end of the ACL to permit all other traffic.
     
    The "GCLIG_mib2cli_parse" error is a bug in the current firmware. We have no specific information on the source of the error, but it will be fixed in the next firmware release (current ETA is Feb 2005).
  • rmd1023

    5 Posts

    163

    0

    Posted December 14th, 2004 13:00



    @DELL-GregG wrote:
    The equivalent of Cisco's "permit ip any any" on the 6024 would be "permit any any any".




    Thanks!
    --Regis
  • rmd1023

    5 Posts

    163

    0

    Posted December 14th, 2004 16:00


    DELL-GregG wrote:
    When you use the ACE "permit ip any any", you are only permitting traffic with a Layer 3 protocol number of 4. Other Layer 3 protocols like ICMP (protocol number 1) will not be permitted. Cisco modified their "permit ip any any" to allow for other common Layer 3 protocols. The equivalent of Cisco's "permit ip any any" on the 6024 would be "permit any any any".





    Actually, I believe the cisco (and foundry, and other vendor) command, rather than just permitting "other common layer 3 protocols" actually allows any valid IPv4 packet without limiting it based on the protocol field in the IP header (byte 10, i think, in the IP header). This would be in contrast to other protocols (appletalk, sna, etc) that might be running in a multiprotocol environment.

    "IP Protocol 4" is just IP-within-IP encapsulation.

    The documentation for the 6024 doesn't specify that "ip" actually means "ip within ip encapsulation" rather than "all valid IPv4 traffic". I suspect there may be an error in http://support.dell.com/support/edocs/network/pc6024/en/clig/acl.htm#1035421:




    NOTE: Using "any" specifies that all IP protocols are permitted. The permit "any" does not imply that other protocols running over IP (e.g., TCP, UDP, etc.) are "permitted".




    The second sentence doesn't make much sense in this context; it would make more sense if it specified that it was referring to "permit ip any" rather than just "permit any", which I'm guessing it does. And nowhere in the documentation does it specify that "ip" means "ip within ip encapsulation" which.

    I would suggest that the documentation should be more clear on this point.