ASA Private VLAN Support
During my time working across various networks – I’ve had the opportunity to come across many interesting technologies (Both old and new). It’s not uncommon to see some environments use a certain feature widely and others not at all. One feature of this nature is Private VLANs (PVLANs). Though not new at all (at least Cisco’s implementation – defined in RFC5517 in 2010 though they were around at least 10 years before that), I’ve seen PVLANs used widely in a few critical production environments. However, firewall products generally do not include support for PVLANs natively.
One of the great things about working for Cisco is having the ability to influence product capabilities to suit the needs of customers. The discussion below describes one feature – PVLAN-support / VLAN Mapping – that I had a part in getting implemented into the Cisco ASA software version 9.5(2).
Below is an overview of Private VLANs and how this feature can be used. I hope to expand upon this in the near future.
What are Private VLANs (PVLANs) and why would I use them?
Ever used internet access in a hotel? If so – you’ve probably used PVLANs.
PVLANS are a way to provide IP connectivity to a range of access devices while restricting their ability to talk to each other even if the devices are on the same subnet. This allows network administrators to provide network access to a wide range of devices but provide access restrictions without having to create a significant number of security policies or define a VLAN/Subnet for each device.
There are more detailed descriptions of PVLANS elsewhere, including the Wiki page HERE.
What if I need to restrict traffic access upstream from the access layer of the network?
Usually you’d do this with routed ACLs or VLAN ACLs on the access or distribution switch. Or perhaps a firewall upstream from your access layer switch. The key point is that prior to to ASA v9.5(2), you couldn’t insert a firewall directly into a PVLAN (either in Layer 2 Transparent or Layer 3 Routed mode).
The Problem – Why didn’t this work before?
Basically is comes down to the fact that in Isolated PVLANs, the ports attached to access devices talk upstream on one VLAN, and the promiscuous devices (such as the router/firewall) talk on another VLAN (i.e. the Primary VLAN), even though they are on the same subnet. This is how the access switch enforces PVLAN access. This will break connectivity for devices that are not PVLAN-aware.
How does the new PVLAN solution on the ASA work?
The ASA associates multiple ingress secondary VLANs to the Primary VLAN (and associated subnet), and makes sure that all return traffic is sent out the Primary VLAN (as if it is the Promiscuous host). Ultimately, the ASA does not need to maintain state of the VLAN mappings after the secondary VLANs have been associated.
The diagram below attempts to graphically explain how this works. This assumes a Layer 3 subinterface but in fact this will work if the ASA is in Transparent mode as well.
What is the configuration syntax?
The snippet below shows the sample syntax. As you can see it’s quite simple.
More information can be found on the Cisco Configuration Guides here.
Don’t switches already have a way to map devices that are ignorant of PVLANs like the Promiscuous Trunk feature?
Yes. This was particularly well-supported on the Catalyst 4500/6500 platforms, however the newer Nexus 7000 platforms have significant limitations – namely the platform is limited to only 16 Primary/Secondary VLAN Pairs on each trunk, which is not adequate in many scenarios.
I hope you find this helpful – Let me know if you happen to use this feature.