First of all, welcome and thanks for reading! Setting up ACLs using the method described by HP is indeed extremely complicated. That’s why, when I found that my simplified CLI method worked, I decided I had to write up this guide for others.
To answer your question re: port range 137-138, it’s just an example. That rule came from an ACL I use to isolate my web server VLAN from my other DMZ VLANs. Why did I permit that specific range? I use an SMB share to back up my web servers’ content and the CIFS/SMB protocol uses those ports. (I actually updated it to range 137-139).
That specific ACL rule may not be applicable to you. To keep the article a manageable size, I decided to defer a tutorial on designing ACLs to a future article. Let me know if you would be interested in such an article (and keep in mind that my offer of helping you design your ACL still stands).
If you want a quick-and-dirty guide for designing ACLs on your L3 switch, I’ll offer the following:
- Defer setting up the ACLs initially and instead concentrate on getting your VLANs set up and everything working on the switch.
- Audit your inter-VLAN traffic. See what ports are in use and who is talking to what.
- Explicitly permit required inter-VLAN traffic, block everything else.
Continuing the example, on one of my web servers, you would see that it was talking to my unRAID server on ports 137-139 (again, due to the SMB connection). I then set up my ACL rule to explicitly allow the connection to my unRAID server, but I do it in such a way that the ACL rule still is limited in scope: I allow my web server to connect to my unRAID server (and ONLY my unRAID server, nothing else) and only on those ports. I then deny all other inter-VLAN traffic from the web server VLAN.
As you gain more experience, you’ll be able to design your VLANs and ACLs right from the start without even having to resort to keeping your ACLs open at the beginning. You’ll also learn how to design your VLANs better. If you realize that you’re starting to have to open (permit) a lot of connections between VLANs, it may make more sense to group those devices together within their own VLAN.
The most important step is to just get started. Perfect is the enemy of good.