topic VSP and ACL's (and some XMC) in ExtremeSwitching (VSP/Fabric Engine)

VSP and ACL's (and some XMC)

XTRMUser — Tue, 12 Apr 2022 17:34:51 GMT

First time poster. A few questions, but related. All VSP's are running VOSS 8.4.3.0

1. I'm trying to limit access to the some ERS switch IP addresses using ACL's. The switches IP addresses are in a VLan. So far, I have IP's of permitted users (network admins), IP's of XMC/NAC servers, deny everybody else. Because these switches have EAP enabled ports, I think I also need to permit IP's of DHCP servers. We are a Windows shop, so do I also need IP's of Active domain controllers/DNS servers?

2. I'm also trying to limit access to VSP switches, also using ACL's. These have CLIP addresses, and are not part of a VLan. Here are the first few lines of a regular inVlan ACL (in docs that I have seen so far).

filter acl 10 type invlan name "Limit access to VSP"
filter acl vlan 10 <vlan number>
filter acl ace 10 10 ...

Since the CLIP addresses are not part of a VLan, should I skip the 2nd line? Or leave it in with a dummy vlan number?

3. Finally, is there some good documentation on VOSS ACL's? I'm aware of https://download.avaya.com/css/public/documents/101008810, but wondering if there is an updated version? Or is there an Extreme/other course about this?

Thanks for any help.

Re: VSP and ACL's (and some XMC)

XTRMUser — Thu, 14 Apr 2022 23:44:05 GMT

In response to #1, I went about solving this the other way. After the IP's of permitted users and XMC/NAC, I'm blocking ports 21,22,23,80,443 and UDP 161. This allows regular EAP traffic, but blocks control access of the switches (which is what I'm after). Unless I missed a port.

I still don't know what do about #2 and #3. Any help is appreciated.

Re: VSP and ACL's (and some XMC)

SamPirok — Mon, 02 May 2022 14:32:29 GMT

Hey there, thanks for your patience while we looked in to this. I would recommend checking out the Traffic Filtering section of the VOSS User Guide for help with 2 and 3.

8.6 VOSS User Guide
8.4 VOSS User Guide

Re: VSP and ACL's (and some XMC)

Ludovico_Steven — Tue, 03 May 2022 12:27:00 GMT

For (2), if you are trying to limit management access to the VSP, you should be looking at the access-policy configuration, rather than ACLs.

Re: VSP and ACL's (and some XMC)

XTRMUser — Tue, 03 May 2022 16:51:59 GMT

Thanks Sam and Ludovico. I'll pursue these avenues more.

Re: VSP and ACL's (and some XMC)

XTRMUser — Thu, 05 May 2022 00:38:45 GMT

Did some digging and experimentation. access-policy will do great, except...

There are 5 services/ports that a VSP switch has open (according to nmap). 4 of them are listed in the access-policy to permit/deny. The missing one is https. So to limit access to a VSP switch, when I can't stop https:, is lacking. The only VSP commands I see are:

web-server enable
no web-server secure-only

We can limit http using access-policy, but not https. The only option is to disable web-server totally, but it is nice to use EDM, which requires web-server 🙂

Any thoughts???

Thanks.

Re: VSP and ACL's (and some XMC)

Ludovico_Steven — Wed, 11 May 2022 16:27:51 GMT

Raised with product management the fact that we are missing https in access-policies at the moment. As this is an easy change, it looks like this will be added in a future release.

Re: VSP and ACL's (and some XMC)

XTRMUser — Wed, 11 May 2022 22:33:58 GMT

It appears (with early limited testing) that blocking HTTPS is done with HTTP. In other words, by denying/permitting HTTP, HTTPS is also denied/permitted. But it would be nice to have it explicitly shown.

Re: VSP and ACL's (and some XMC)

Ludovico_Steven — Fri, 13 May 2022 10:06:52 GMT

Yes, I also tested it. So, thinking about this again, if the access-policy "http" protocol allows or denies both of http & https at the same time, then this means that it does actually work for https. So the question now is whether there is any value in using access-policies to allow some users to access the web interface with HTTP and other users with HTTPS. And I don't quite see a use case for that. You probably want allow http/https, as you can do today, and then simply set the web-server to only operate with HTTPS. Why change the existing behaviour ?
Note that RESTCONF is using a different HTTP stack internally, hence the use of a different 8080 port number. So we would probably simply add "restconf" as another option under access-policies.