HP Procurve 5406zl - ACL issue

Question

I'm having an issue with an ACL on a VLAN interface. I've followed HP's documentation here: http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02609963-3.pdf

I want to do the following:

VLAN 101 should only be able to communicate to VLAN 50 - no other VLANs, no internet access.

Initially, I tried the following access list:

ip access-list extended "SecureContent"
    10 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255
    20 remark "SecurityVLAN"

I applied this ACL to VLAN 101 "in" with the following command:

  vlan 101
    ip access-group "SecureContent" in

This configuration results in zero communication on that VLAN: The IP of 192.168.101.2 on port A1 cannot ping 192.168.101.1, the switch VLAN IP. If I change the access list to:

10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255 
20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255

...this results in clients on the VLAN being able to ping their default gateway, but not the 50.1 gateway. That doesn't make any sense to me - the VLAN 101 IP interface should be considered logically "inside" that VLAN 101, correct?

I have tried various versions of this access list, even going so far as to do just a standard access list blocking a single IP yet permitting everything else with a "permit ip any any" statement - and this still results in zero inter or intra-vlan traffic - the host on that VLAN can't even ping its own gateway if I apply the list in the inbound direction (I also tried a variant in the outbound direction - exactly the same result!)

Below is the switch configuration:

    Running configuration:

; J8697A Configuration Editor; Created on release #K.15.09.0012
; Ver #03:01.1f.ef:f2
hostname "HP-5406zl"
module 1 type j8702a
module 2 type j8708a
module 3 type j9546a
module 4 type j8708a
power-over-ethernet pre-std-detect
ip access-list extended "SecureContent"
     10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255
     20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255
   exit
ip route 0.0.0.0 0.0.0.0 172.16.0.1
ip routing
snmp-server community "public" unrestricted
snmp-server contact "Person" location "Place"
vlan 1
   name "DEFAULT_VLAN"
   no untagged A1-A20,A23-A24,B1-B4,C1-C8,D1-D4
   untagged A21-A22
   ip address 192.168.1.10 255.255.255.0
   jumbo
   exit
vlan 50
   name "Editors"
   untagged A2-A19,B1-B3,C1-C8,D1-D4
   tagged A23-A24
   ip address 192.168.50.1 255.255.255.0
   jumbo
   exit
vlan 100
   name "IO"
   tagged A23-A24
   ip address 192.168.100.1 255.255.255.0
   exit
vlan 101
   name "SecureContent"
   untagged A1
   ip address 192.168.101.1 255.255.255.0
   ip access-group “SecureContent” in
   exit
vlan 200
   name "Corp"
   tagged A23-A24
   ip address 192.168.200.1 255.255.255.0
   ip helper-address 192.168.50.2
   exit
vlan 800
   name "IT"
   untagged A23-A24
   ip address 172.17.0.1 255.255.255.0
   exit
vlan 899
   name "DMZ"
   untagged B4
   tagged A23-A24
   ip address 172.18.0.1 255.255.255.0
   jumbo
   exit
vlan 900
   name "Routed"
   untagged A20
   tagged A23-A24
   ip address 172.16.0.2 255.255.255.252
   exit
vlan 999
   name "VLAN999"
   no ip address
   exit

EDITED to add relevant chassis information:

  Software revision  : K.15.09.0012         Base MAC Addr      : 002561-f80000
  ROM Version        : K.15.30              Serial Number      : XXXXXXXX
  Allow V1 Modules   : Yes     

         Opacity Shields    : Not Installed

Thanks in advance for your help!

I am trying to block icmp ping between specific vlans , when I apply same config in cisco its working find but when try it on hp5400 series it’s not working. Let say : Vlan-10 (192.168.10.1/24) Vlan-20(192.168.20.1/24) The sample config would be as below.. # ip access-list extended "130" 10 deny icmp 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0 20 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Vlan 10 ip access-group 130 in Please advise !!!!! — khan, Sep 14 '16 at 10:06

score 7 · Accepted Answer · edited Jun 11 '14 at 03:34

7

According to the Access Security Guide for your device, the first address and mask of an ACE is source and the second address and mask is the destination. (Just in case, an ACE is an Access Control Entry; that is any line an access-list is made of)

ACE 20 of your ACL states source 192.168.50.0/24 and destination 192.168.101.0/24, then you apply the ACL at VLAN 101 input; however, your VLAN 101 is 192.168.101.0/24, so any input traffic at VLAN 101 would have source address in 192.168.101.0/24. So ACE 20 in your ACL is wrong, you need an ACE with action permit, source 192.168.101.0/24 and destination 192.168.50.0/24.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255

Regarding the way back for this traffic, it will cross VLAN 101 outbound, so ACL should not be applied to this traffic and it should be allowed.

If traffic back is not allowed then you need to add the way back in your ACL.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
    20 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255

EDITED to change the line above to reflect proper ACL structure of numbered entries. (10, 20, etc).

edited Jun 11 '14 at 03:34

Mike Pennington

29,876
11
78
152

answered Jun 06 '14 at 18:19

Daniel Yuste Aroca

2,884
5
24
43

Interesting - the HP devices handle that ACL logic totally differently from the Cisco stuff. Thanks for your insights. I'll try this! – Panther Modern Jun 06 '14 at 19:07
1

What are the differences you are finding? My background is mainly with cisco gear and I dont find this config much different... – Daniel Yuste Aroca Jun 06 '14 at 19:13
All my ACLs on Cisco gear work without the entries for return traffic. – Panther Modern Jun 06 '14 at 19:18
To clarify: I've never had to build return traffic ACLs on Cisco gear except on older Pix firewalls. All the switch ACLs seem to work fine with the single entries I use. – Panther Modern Jun 06 '14 at 19:20
Just to make sure, first you need to reverse the ACE 20 in your ACL, then try if it works. If it works you don't need to configure the way back – Daniel Yuste Aroca Jun 06 '14 at 19:46
I have edited my answer regarding way back for the traffic – Daniel Yuste Aroca Jun 06 '14 at 20:02
NOTE: Your old ACL worked. Your new one does not. – Panther Modern Jun 06 '14 at 20:09
1

Thanks for confirmation Panther Modern, I have edited answer again to make it right according to your experience – Daniel Yuste Aroca Jun 06 '14 at 20:36

score 2 · Answer 2 · answered Jun 06 '14 at 17:36

It looks like this problem is due to the way that HP's networking gear handles ACLs versus Cisco (which is my networking background).

According to this document, HP ACLs are stateless, and must contain bidirectional traffic entries (for originating traffic and return traffic): http://tinyurl.com/qbfemk6 (Link to PDF on HP's site).

This is in contrast to the Advanced Traffic Management guide above, which displays configuration examples that do not implement or account for this "quirk": the examples contain no such return traffic entries.

Lessons Learned: Do not trust manufacturer documentation to be consistent and accurate.

HP Procurve 5406zl - ACL issue

2 Answers2