Procurve 5412: ACL not working correctly

ACL's are processed "top down". So the first statement is matching all traffic and denying it.

So move statement 10 to the end (statement 40) and it will work as you desire.

Top-down implies that:
FIRST: deny all traffic
SECOND: allow 10.254.120.122
THIRD: allow 10.254.0.27

That isn't what's happening.  It also clearly isn't practicing implicit DENY ALL as I would expect it to.

I tried another configuration:

ip access-list standard "1"
   10 deny 192.168.254.1 0.0.0.255 log
   20 deny 192.168.253.1 0.0.0.255 log
   30 permit 10.254.0.1 0.0.0.255 log
   40 permit 10.254.120.1 0.0.0.255 log
   exit

Logic tells me that the above would:
FIRST deny all traffic from subnet 192.168.254.x
SECOND deny all traffic from subnet 192.168.253.x
THIRD permit all traffic from subnet 10.254.0.x
FOURTH permit all traffic from subnet 10.254.120.x

No traffic at all is permitted above.  So you're suggesting I rework them as "bottom-up", since top-down clearly isn't how it's being processed?

I'll give that a try.  I also tried explicit DENY with a subnet PERMIT and it didn't work.

Thx.
SteveInNV

That isn't what's happening.  It also clearly isn't practicing implicit DENY ALL as I would expect it to.

From your initial post:

The following is what I have so far; it basically restricts ALL access, including the IP addresses I want to permit.

You originally said that the ACL "restricts ALL access".  And now you're saying that "isn't what's happening."

So what is happening?

Please post the relevant portions of the config from the switch.  It may be a typo that's hard to see.

I was noting that "top-down" as you suggested isn't what was happening.  My config in the top post (looking at top post ONLY) was not working; your suggestion of "top-down" as applied to that config was not working (please refer to my initial post).

Since then I've tried several configurations, including those noted in my first reply ("I tried another configuration").  The ALSO did not work: no traffic was permitted from the PERMIT subnets.

As you suggested, I moved the explicit deny to the bottom ("bottom-up") and it didn't work either: all traffic was denied.  I tried that configuration on both the port and the VLAN individually, and no traffic from any subnet was permitted.  Clearly there's something else at work here.

This is the only ACL on this switch, and there are multiple subnets & VLANs configured on it.

Thanks for any suggestions.
SteveInNV

Don, thanks for replying.  The below are two of the most recent attempts; neither work.

First (bottom-up, did not work: no subnets have access):
-----------------------------
ip access-list standard "1"
   10 permit 10.254.0.1 0.0.0.255 log
   20 permit 10.254.120.1 0.0.0.255 log
   30 deny 0.0.0.0 255.255.255.255 log
   exit

Second (top-down, did not work: no subnets have access):
-----------------------------
ip access-list standard "1"
   10 deny 0.0.0.0 255.255.255.255 log
   20 permit 10.254.0.1 0.0.0.255 log
   30 permit 10.254.120.1 0.0.0.255 log
   exit

The server in question is on 10.135.1.x; the switch port (B13) is configured for VLAN 135.  My workstation IPs are 10.254.0.x and 10.254.120.x and port is config'd for all VLANs (including the VLAN for this test server, 135).

The ALSO did not work: no traffic was permitted from the PERMIT subnets.

That's exactly what Don is telling you.
When match is found (deny all - first statement) - it is game over.
You need to set more specific tasks first.
permit host
deny host
permit network
deny network
permit all
deny all

If deny all if the first statement in ACL it is the only match that will be found, it  does not matter what comes after that statement since it the rest of statements will never be processed.

This probably should be
-----------------------------
ip access-list standard "1"
   10 permit 10.254.0.0 0.0.0.255 log
   20 permit 10.254.120.0 0.0.0.255 log
   30 deny 0.0.0.0 255.255.255.255 log
   exit

Did you place ACL on good place and in right direction.

Predrag, thanks for replying!

This this should have worked based on that, correct?

ip access-list standard "1"
   10 permit 10.254.0.1 0.0.0.255 log
   20 permit 10.254.120.1 0.0.0.255 log
   30 deny 0.0.0.0 255.255.255.255 log
   exit

The above did not work: all subnet traffic was denied access.  I'll go back to just denying access to specific subnets and see if that works; I'm clearly not having any luck with exceptions to a DENY ALL policy.

Thanks.
SteveInNV

Did you place ACL on good place and in right direction.

Could you paste your config (remove sensitive parts), and maybe your topology?

Predrag, thanks for replying!

As for the last octet in the IP address mask, I've tried both "0" (which is natural to me) and "1", which the HP documentation says to use.

I also just tried this configuration applied to the port the test server is connected to to keep it simple:

ip access-list standard "1"
   10 permit 10.254.0.1 0.0.0.255 log
   20 permit 10.254.120.1 0.0.0.255 log
   30 deny 192.168.254.1 0.0.0.255 log
   exit

The above did not work; my workstation on the PERMIT subnets above was unable to contact the server on subnet 10.135.1.x.  The clause in question applied to the port was "ip access-group 1 in" to block inbound traffic on the port.

Thanks.
SteveInNV

I just found a post on a different site which says that these masks as required by HP must be entered as bi-directional (as in source IP (and mask) THEN destination IP (and mask).  The HP documentation only states a single IP address (and mask).

Can someone confirm or deny this?  Does this rule apply to EXTENDED ACLs and not standard ACLs, or both?

Thanks!
SteveInNV

This this should have worked based on that, correct?

ip access-list standard "1"
   10 permit 10.254.0.1 0.0.0.255 log
   20 permit 10.254.120.1 0.0.0.255 log
   30 deny 0.0.0.0 255.255.255.255 log
   exit

Not if it  applied in wrong direction!!!!
If it is applied in wrong direction it will block all traffic.

And again this is inconsistent
10 permit 10.254.0.1 0.0.0.255 log

And - no need for EXTENDED ACLs in your case.

Once again, please post the relevant portions of the config from the switch.  Not just the ACL, but the commands that are applying it to a port or interface.  Without that, all we can do is guess.

Don - simple logic - if  all traffic is always blocked...

I think you're confused. I am not the author of this question.  The only query I have outstanding on this question is for the relevant portion of the configs.

Pedrag: see the screencap below of a page in the HP Procurve ADv Traffic Mgmt Guide for 5400 series.  It's the quickest example of the (admittedly) odd way the Procurve manual shows how subnet masking in the ACLs works.  
Don: below are the relevant portions of the current config you requested...  Please note that for the below config I changed the ".1" IP address final octet to ".0" to demonstrate to Pedrag that, according to HP documentation, it has no effect on what I'm trying to accomplish.

ip access-list standard "1"
   10 permit 10.254.120.0 0.0.0.255 log
   20 permit 10.254.0.0 0.0.0.255 log
   30 deny 192.168.253.0 0.0.0.255 log
   40 deny 192.168.254.0 0.0.0.255 log
   exit

interface A5
   name "SGB_Office_D70"

interface B13
   name "AMKM_Server"
   ip access-group "1" in
exit

vlan 135
   name "AMKM_Isolate"
   untagged A5,B13
   ip address 10.135.1.1 255.255.255.0
   exit

The above configuration yielded the same results: unable to access the server (port B13, subnet 10.135.1.x) from workstation (port A5, subnets 10.254.0.x & 10.251.120.x): no ping, no rdp, etc.

Thanks for looking, guys.  I guess the next step is to try using an extended ACL to get the task accomplished.
SteveInNV

Not sure I follow if there is an issue with the command structure. I've done many ACL's on 5400 series switches. Whatever digits you use in the address are irrelevant when you use a "255" in the wildcard mask.

Or put another way, 192.168.1.0 0.0.0.255 will match the exact same traffic as 192.168.1.1 0.0.0.255.

In short, it doesn't matter what you put in the last octet if the wildcard mask for that octet is "255".

The above configuration yielded the same results: unable to access the server (port B13, subnet 10.135.1.x) from workstation (port A5, subnets 10.254.0.x & 10.251.120.x): no ping, no rdp, etc.

This is a little confusing (for me).

Are you saying that there are servers that have IP addresses of 10.135.1.x that are connected to port B13?

And there are workstations with IP addresses of 10.254.0.x & 10.135.120.x which are connected to port A5?

If I'm not correct, here what I would like to know:

1.

What port are the servers connected to and what are their IP addresses.

2.

What port are the workstations connected to and what are their IP addresses.

Don, thanks for replying.  I didn't have an issue with the .1 vs .0... :)  I was just demonstrating to Predrag that it didn't much matter according to HP docs.

The server in question is IP addy 10.135.1.5 (gateway 10.135.1.1) on port B13 (VLAN 135) of the switch.  My workstation is 10.254.0.27 and 10.254.120.122 on port A5 (all network VLANs including 135) of the switch.  These are the only two machines that are relevant to the issue and the only two ports on VLAN 135.  Without any ACL in place access to the server is possible from anywhere on the network (any VLAN); implementing the above ACL yields NO access to the server from any computer on any VLAN on any subnet.

I have a feeling the issue is something simple, but I'm approaching the point where it all becomes moot: I'll have to dedicate a workstation for this server for the user off-network instead of setting it up the way it should be done.

Thanks.
Steve

Well, I think that I see a problem.

What is between the hosts and the 5412 port A5?  I'm guessing there's a router or a multilayer switch?

If so, then you probably want the ACL applied to port A5 as inbound.

Don, thanks for replying.  The server is wired into port B13 on the 5412 (B13 is untagged on VLAN 135) and there's a Cisco workgroup switch between my workstation and port A5 on the 5412 (A5 is tagged on VLAN 135, but I've also tried it as untagged; no effect).

I'm trying to isolate the server (port B13) from all other traffic, not my workstation (port A5).  Setting up the ACL on port A5 OUT would kinda make sense, but, once again, I'm trying to isolate the server.  I'll physically take my workstation to another office that is directly wired into the 5412 as well to test; however, I don't see the Cisco switch as a cause of the problem.

Thanks for your suggestion!
Steve

No. That's not I'm trying to say.

VLAN is synonymous with IP network. Which means, that if two devices are on the same VLAN, they would need to have IP addresses on the same IP network.

So you have host sending traffic in on A5 from an IP address of 10.254.0.27 going to 10.135.1.5 out B13. They are on two different networks but they are on the same VLAN.  Unless there's a device routing between the 10.254.0.0 network and the 10.135.1.0 network, it's not going to work... period. The ACL isn't the problem.

Don, that's exactly what the 5412 does: IP routing is enabled and it happily routes traffic between a large number of VLANs (IP subnets) here all day long.  The 5412 is a L3 switch.  Sitting on VLAN 100 I access servers on VLAN 200 and print to printers on VLAN 300 (for example, all different subnets).  With the 5412 it's a non-issue.  

Thanks.
Steve

Sitting on VLAN 100 I access servers on VLAN 200 and print to printers on VLAN 300 (for example, all different subnets).

But that is not what is happening here.

You have a host on VLAN 135 trying to communicate with another host on VLAN 135.  But they are on different IP networks.  

Now if port A5 were in a different VLAN, then this may work.  

But as long as the hosts are in the same VLAN but not on the same network there is no way they will be able to communicate with the server unless there is an external router between them and port A5.

Here's an example of how this could work.

With this config, host 10.254.0.27 will be able to communicate with the server at 10.135.1.5

interface A5
   name "SGB_Office_D70"

interface B13
   name "AMKM_Server"
exit

vlan 135
   name "AMKM_Isolate"
   untagged B13
   ip address 10.135.1.1 255.255.255.0
   exit

vlan 254
   name "Hosts"
   untagged A5
   ip address 10.254.0.1 255.255.255.0
   exit

Select allOpen in new window

Don, thanks for reply.

That *is* how the switch is configured.  For brevity's sake I did not include all of the VLAN configurations because they really aren't relevant to the question.  Just as a test I removed the Cisco switch from the equation and patched the workstation directly into an untagged port on the 10.254.0.x subnet and it still didn't work (with the ACL in place).  The above is how we have been working for years.  Without an ACL in place every machine on the network (all subnets/VLANs) can communicate perfectly with the test server--- yes, machines sitting on 10.254.x.y and 192.168.254.x and 10.0.1.x and 172.17.254.x can communicate perfectly with the test server on 10.135.1.x: no routers or switches other than the core 5412.  Routing is *not* an issue here.  If it were no machine would EVER be able to communicate with the server.

I'll try another board for suggestions, but thank you very much for some important feedback!
SteveInNV

For anyone still following this thread, I found the resolution. It turns out that, according to HP, ACLs applied to VLANs are relative to the router and not to the port/device you're applying the ACL to.  Rather than thinking in terms of traffic inbound to the machine/VLAN in question, it is (in my case) based on traffic outbound of the router (which, technically, all internal traffic *is* outbound from the router).

This was never a traffic routing issue (ala traffic flow across routed vs non-routed network segments).  Thanks for Predrag for planting that bug in my head about the traffic flow direction.  :)

This comment and attached manual helps make some of the previous comments by others more current as of 4/2016.

HPE does not discuss ACLs to any great degree in the current Advancement Traffic Management Guide.  HPE now uses the Access-Security-Guide manual to better describe ACLs.

This wildcard calculator is great and easy to use:  http://www.subnet-calculator.com/wildcard.php
HPE-access-control-emr_na-c04777632-.pdf