HP Procurve and Protecting VLANs with ACLs

How to protect a OOB Management VLAN from access, or protect a VLAN from being directly plugged into by a switch from another VLAN (with another subnet, or  another DHCP server)

Now some of this is still under testing, but I feel that I have pretty much mastered the art of ACLs to protect a VLAN such as one used to manage a bunch of devices such as routers, switches, firewalls, UPS, environmental monitors, or just traffic that you would rather not see have access to a VLAN or devices plugged into a Procurve switch.

Now, it is a best practise network wise to use ACLs to block traffic at the source. So this may seem a little backwords, but I want to use this ACL as a last line of defence to block traffic on the port as it leaves out of the vlan to the device. So we will be using the “out” and not the “in” for the first part.

Another important thing to remember to about ACLs, is that if you do not list a permit or deny statement anything not on the list will be blocked. So as a best practise I will only list those IP addresses that need access. Also you have the option of using an extended or a standard ACL list. Again I will keep this simple, if you want more flexability to block only certain protocols or even access to only a portion of a subnet then you should look into extended ACLs, for this exercise we will only be permiting source IP addresses (all protocols) using a standard ACL.

Note: these ACLs are considered RACLs, and are only applied if IP Routing is enabled on the switch (Layer 3), if this is just a Layer 2 switch then you may want to try a VACL instead. I will probably post information on a VLAN ACL later, but it controls all traffic entering a switch from a particular VLAN. So with that said I’m assuming you will be using a Layer 3 enabled switch for this exercise.

 Here is the ACL I will create for access to devices on my Out Of Band (OOB) Mangement Interfaces on my devices:

ip access-list standard "OOB-Access-out"
   1 remark "OOB subnet"
   2 permit
   10 remark "NPM System"
   11 permit host
   20 remark "IT Department"
   21 permit
   30 remark "Managemnet Workstation"
   31 permit host

Now the “Out” part means as the packet leaves out a port on the switch it will be applied. This can mean a number of things but again it is important to keep it simple. so now and just focus on the primary goal of only allowing authorized subnets access to management devices.

Applying to your vlan is simple

vlan 6 ip access-group OOB-Access-out out

Observe I used out instead of in. In our next example I will use an “in” so that I block and avoid multinetting my vlan with unauthorised traffic.

ip access-list standard "OOB-Access-in"
1 remark "OOB subnet"
2 permit

Applying the VLAN is the same but remember the “in” instead of the out

vlan 6 ip access-group OOB-Access-in in

The above Standard ACL should only allow devices configured with an IP address to access this VLAN, you may need to modify this a bit to allow other traffic, but with a little testing this could protect your network from for example someone pluging a cable in one jack for one network into the other network with another VLAN causing all sorts of strange traffic such as a DHCP handing out the wrong IP addresses.

There is a lot more you can do with ACLs, and extended ACLs offer much more, but I would recommend getting used to how standard ACLs first, then work with extended ACLs.

Windows Filtering Platform Audit Noise

Did you know that Windows Server 2008 and 2008 R2, as well as Vista can pump out just as many audit logs as your standard hardware firewall. I can understand some audit trails for file access and user account changes but every single TCP and UPD connection is a little over considering windows is already logging this in the firewall log. If your tracking down security issue on you network and you have an SIM trying to correlate all these logs then most of these additional logs are just noise.

There are a couple of ways of dealing with this little issue, the one machine at a time or the GPO. For me the Group Policy option is a must as I don;t have time to go through every server and every workstation that might have these audit logs turned on. The main one I want to focus on is called the “Audit Filtering Platform Connection”

After much searching on the internet I found a pretty good blog that pointed me in the right direction:

computer configuration –> policies –> windows settings –> security settings –> advanced audit policy configuration –> audit policies –> object access. Then double-click “Audit Filtering Platform Connection” and check only the box next to “configure the following audit events.” DO NOT CLICK THE OTHER TWO BOXES. Repeat for “Audit Filtering Platform Packet Drop”

For the one system solution use these command line options:

auditpol /set /subcategory:”Filtering Platform Packet Drop” /success:disable /failure:disable
auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:disable


Testing Branch Network Bandwidth

Now it is easy to run a speedtest against your internet connection, but what if you want to test the speed between two branch offices.

The solution is iPerf.exe. A simple commandline tool you can setup on your windows servers and run speeptests to ensure you are getting what your paying for from your provider.

You can download the current version here:

On the server run:
iperf.exe -s

On the Client run:
iperf.exe -c x.x.x.x

Where x.x.x.x equals the IP address of your server. Check out the link above for more information and sample input. I’m planning to add a custom action to my Lansweeper deployment, when I get a chance to think it through, but command tools like these make for great custom scripts and actions for other plugins.