Wired Intelligent Edge

 View Only
last person joined: yesterday 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution

Extended ACL's on Procurve 5400 series

This thread has been viewed 0 times
  • 1.  Extended ACL's on Procurve 5400 series

    Posted Jun 02, 2017 02:14 PM

    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


    #VLAN
    #ACL
    #ExtendedACL
    #5400