Permitting specific traffic between hosts setup on 'Private VLAN Edge'

Started by seanpbrowne, May 28, 2020, 04:29:44 AM

Previous topic - Next topic

seanpbrowne

Hi,

I have a client using Cisco Private VLAN Edge (switchport protect) which is denying traffic between peers on the same switch/subnet. Excellent.

Is it possible, and if it is, what is the approach to permit traffic between the hosts on a single port? (Whilst maintaining the rest of the isolation).

Or would that require a different solution.

Thanks,
Sean

wintermute000

I can't recall off the top of my head but there are different types of private ports there's one that can be accessed by other private ports ( community?)

Otanx

Wintermute is right. The feature you are looking for are community ports. That lets a subset of ports talk between each other. The problem is a port can only be part of one community. This can cause it to be complicated if you have a host "M" that needs to be able to talk to hosts A, B, C and hosts X, Y, Z, but you don't want A, B, C talking to X, Y, Z.

Another way of doing this (the way we do it) is to use 802.1x to authenticate the host, and download an ACL to the port. That ACL can be different for every host if you want. There are size limits on the ACLs, but this works pretty well for us.

-Otanx

Dieselboy

Quote from: Otanx on May 28, 2020, 08:34:43 AM
Wintermute is right. The feature you are looking for are community ports. That lets a subset of ports talk between each other. The problem is a port can only be part of one community. This can cause it to be complicated if you have a host "M" that needs to be able to talk to hosts A, B, C and hosts X, Y, Z, but you don't want A, B, C talking to X, Y, Z.

Another way of doing this (the way we do it) is to use 802.1x to authenticate the host, and download an ACL to the port. That ACL can be different for every host if you want. There are size limits on the ACLs, but this works pretty well for us.

-Otanx

This forum doesnt have a like button, so here is a patch: 👍

I didnt know you could do that with the dot1x and ACL - that's handy to know  :)

Otanx

Quote from: Dieselboy on June 04, 2020, 05:01:30 AM
Quote from: Otanx on May 28, 2020, 08:34:43 AM
Wintermute is right. The feature you are looking for are community ports. That lets a subset of ports talk between each other. The problem is a port can only be part of one community. This can cause it to be complicated if you have a host "M" that needs to be able to talk to hosts A, B, C and hosts X, Y, Z, but you don't want A, B, C talking to X, Y, Z.

Another way of doing this (the way we do it) is to use 802.1x to authenticate the host, and download an ACL to the port. That ACL can be different for every host if you want. There are size limits on the ACLs, but this works pretty well for us.

-Otanx

This forum doesnt have a like button, so here is a patch: 👍

I didnt know you could do that with the dot1x and ACL - that's handy to know  :)

You are welcome. I learned it a few years ago. We wanted to segment out different systems, but didn't like the limitations on having the system change VLANs on 802.1x authentication changing. So we found you could download an ACL, and get separation without having to change VLANs. We write the ACL "backwards" as well. The ACL we apply to most stuff is a deny for all other client subnets then a permit any. However we also have printer ACLs that get just permits to the print server, and some other "IOT" like stuff that gets dedicated ACLs.

-Otanx

wintermute000


deanwebb

Quote from: wintermute000 on June 05, 2020, 05:21:33 AM
Mind you, you can't change that ACL without a re-auth :)



This is true... but if you have a static device on that port, having a static ACL can help with segmentation like this.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Otanx

Quote from: wintermute000 on June 05, 2020, 05:21:33 AM
Mind you, you can't change that ACL without a re-auth :)

Yep, not a major issue. We set reauth for every 10 minutes I think. So worst case you are waiting 10 minutes. However, those ACLs do not change very often. They are just there to block the east/west traffic because we shouldn't have any client to client stuff in our environment. The more specific ACLs are all on the firewall that leads to the rest of the network.

The bigger issues are no syntax checking on the ACLs. To your RADIUS server it is just text that it needs to send. You accidentally type dny instead of deny? The RADIUS server will send that typo to the switch all day long, and you get weird errors. Also length of the ACLs can become limiting if you need to be more granular. You can't have more than 4K characters including spaces in the ACL. Not too bad as long as you don't do anything crazy

-Otanx

deanwebb

Also, remember that TCAM memory is where all the ACLs go. Too many ACLs and the switch dies from TCAM memory exhaustion.

This is a very real consideration in NAC and is why dynamic VLAN assignment will scale better for large-scale provisioning of services if you're wanting to go big.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

seanpbrowne


config t

Customer from a few contracts ago did dynamic VLAN assignment through dot1x and had a quarantine VLAN set up for clients that failed vulnerability scans for whatever reason. It worked great in that it only permitted communication with patching servers and didn't route outside the campus. The downside was that the client had to be filtered through the ticketing system and the AD security group was manually applied by a sys-admin. Then it had to be patched by IA.. then it had to be kicked back to systems.. probably visited networks first because "I can't internet" Whole process took about a week. Sometimes more if a patch didn't take.

The difference is we had the ACL's permanently configured on the core switch where the SVI's live and they were not assigned dynamically.
:matrix:

Please don't mistake my experience for intelligence.

Otanx

Quote from: deanwebb on June 06, 2020, 08:08:12 AM
Also, remember that TCAM memory is where all the ACLs go. Too many ACLs and the switch dies from TCAM memory exhaustion.

This is a very real consideration in NAC and is why dynamic VLAN assignment will scale better for large-scale provisioning of services if you're wanting to go big.

This is a valid concern, and another reason we left the dACL very simple. I just looked, and our longest dACL is 6 lines. Most are 2 or 4. I can't find it now, but remember reading something about the Catalyst line optimizing TCAM, and only keeping one copy of the ACL if it is applied to multiple ports. Can't find that doc now so maybe I didn't. If not then worst case for us would be 288 lines (6 lines times 48 ports).

-Otanx

deanwebb

Yeah, I get customers where the ACL for build servers is what kills the "short and simple" approach.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.