Extended ACL's on Procurve 5400 series

[jdixon]

I'm having a hard time understanding something with procurve and applying extended ACL's to VLANS. I'm applying them with the direction IN which I thought meant the ACL is applied to all packets coming IN to the VLAN. What I'm noticing though is I have to reverse the Source/Destination on the ACL.

Example:

ip access-list extended "CUST-Access-IN"
     502 deny ip 10.1.0.0 0.0.255.255 172.17.0.0 0.0.255.255 log
     503 deny ip 172.17.0.0 0.0.255.255 172.17.0.0 0.0.255.255 log
     600 remark "==== Allow All ==="
     601 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 log
   exit

vlan 2010
   name "VLAN2010"
   tagged F1-F2,F4,K1-K4,L1-L4,Trk50
   ip address 172.17.12.254 255.255.255.0
   ip access-group "CUST-Access-IN" in
   exit

Now VLAN 10 doesn't have any ACL. So when I try to communicate from VLAN 2010 (172.17.12.4) to VLAN 10 (10.1.0.2) it works just fine. Even though you can see the deny from SOURCE 10.1.0.0/16 to 172.17.0.0/16.

So if I change it around:

ip access-list extended "CUST-Access-IN"
     502 deny ip 172.17.0.0 0.0.255.255 10.1.0.0 0.0.255.255 log
     503 deny ip 172.17.0.0 0.0.255.255 172.17.0.0 0.0.255.255 log
     600 remark "==== Allow All ==="
     601 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 log
   exit

Then it finally blocked it when I telnet from 172.17.12.4 to 10.1.0.2 on port 88.

How come the source/destination is REVERSED in my mind?? If you look at wireshark you can see the Source/Destination and the ports. Yes, 172.17.0.0 should be able to hit 10.1.0.2 on port 88 but the traffic coming back shouldn't be allow in this example. It goes From 60214(random) -> 88 and then comes back 88 -> 60214 which should be blocked