Private VLANs

To begin with, let’s recall that VLAN is essentially a broadcast domain.

Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast “subdomains”, introducing subVLANs inside a VLAN. 

As we know, Ethernet VLANs can not communicate directly with each other - they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS - since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device - such as router. 

However, there is a difference here. In real life, different VLANs usually map to different IP Subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using local Proxy ARP). On its side, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

For our sample configuration, we will take VLAN 1000 and divide it into three PVLANs - sub-VLAN 1012 (R1 and R2), sub-VLAN 1034 (R3 and R4) and sub-VLAN 1055 (router R5 only). Router R6 will be used as layer 3 device, to resolve the layer 3 communication issue. Look at the figure above for reference. We define VLAN 1000 as “Primary” and classify the ports, assigned to this VLAN, based on their types:

Promiscuous (“P”) port: Usually connects to a router. This port type is allowed to send and receive L2 frames from any other port on the VLAN
Isolated (“I”) port: This type of port is only allowed to communicate with “P”-ports - i.e., they are “stub” port. You commonly see these ports connecting to hosts.
Community (“C”) port: Community ports are allowed to talk to their buddies, sharing the same community (group) and to “P”-ports.

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different types of ports. First comes the Primary VLAN - VLAN 1000 in our example. This type of VLANs is used to forward frames downstream from “P”-ports to all other port types (“I” and “C” ports) in the system. Essentially, Primary VLAN embraces all ports in the domain, but only transports frames from the router to hosts (from “P” to “I” and “C”). Next come “Secondary” VLANs - they correspond to “Isolated” and “Community” ports. These VLANs transport frames in the opposite direction (upstream) - from “I” and “C” ports to “P” ports.
Isolated VLAN: forwards frames from “I” ports to “P” ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames upstream to the P-ports of the primary VLAN.

Here is a simplified overview of how Private VLANs work:

The Primary VLAN delivers frames downstream from the router (promisc port) to all mapped hosts; The Isolated VLAN transports frames from the stub hosts upstream to the router; The Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards “P”-ports. The original Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding procedure within boundaries of primary/secondary VLANs. Naturally, private VLANs could be trunked. The secondary VLAN numbers are used to tag frames, just as with regular VLANs, and the primary VLAN traffic is trunked as well. However, you need to configure Private VLAN specific settings (bindings, mappings) on every participating swtich, for it’s not possible to use VTPv2 to dissiminate that information . This due to the fact that VTPv2 has no TLVs to carry private VLANs information, and besides, private VLANs are not intended to be floodes across the whole management domain. Not to mention that using VTP in enterprise networks is usually not a good idea :). Though VTPv3 was designed to overcome this limitation among others.

Let’s move to the configuration part, based on the diagram above. What we have is primary VLAN 1000, Isolated VLAN 1005 (R5) Community VLAN 1012 (R1, R2) and Community VLAN 1034 (R3, R4).

Step 1:

First, disable VTP, i.e. enable VTP transparent mode. After disabling VTP, create Primary and Secondary VLANs and bind them into PVLAN domain:

SW1:

vtp mode transparent

!

! Creating primary VLAN, which is shared among secondary’s

!

vlan 1000

private-vlan primary

!

! Community VLAN for R1 and R2: allows a “subVLAN” within a Primary VLAN

!

vlan 1012

private-vlan community

!

! Community VLAN for R3 and R4

!

vlan 1034

private-vlan community

!

! Isolated VLAN: Connects all stub hosts to router.

! Remember - only one isolated vlan per primary VLAN.

! In our case, isolates R5 only.

!

vlan 1055

private-vlan isolated

!

! Associating the primary with secondary’s

!

vlan 1000

private-vlan association 1012,1034,1055

This step is needed is to group PVLANs into a shared domain and establish a formal association (for syntax checking and VLAN type verifications). Repeat the same operations on SW2, since VTP has been disabled.

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary. Also, enable trunking between switches, to allow private VLANs traffic to pass between switches.

SW1:

!

! Community port (links R1 to R2 and “P”-ports)

!

interface FastEthernet0/1

description == R1

switchport private-vlan host-association 1000 1012

switchport mode private-vlan host

spanning-tree portfast

!

! Community port (links R3 to R4 and “P”-ports)

!

interface FastEthernet0/3

description == R3

switchport private-vlan host-association 1000 1034

switchport mode private-vlan host

spanning-tree portfast

!

! Isolated port (uses isolated VLAN to talk to “P”-ports)

!

interface FastEthernet0/5

description == R5

switchport private-vlan host-association 1000 1055

switchport mode private-vlan host

spanning-tree portfast

!

! Trunk port

!

interface FastEthernet 0/13

switchport trunk encapsulation dot1q

switchport mode trunk

SW2:

interface FastEthernet0/2

description == R2

switchport private-vlan host-association 1000 1012

switchport mode private-vlan host

spanning-tree portfast

!

interface FastEthernet0/4

description == R4

switchport private-vlan host-association 1000 1034

switchport mode private-vlan host

spanning-tree portfast

!

! Trunk port

!

interface FastEthernet 0/13

switchport trunk encapsulation dot1q

switchport mode trunk

Next, Verify the configuration on SW1:

Rack1SW1#show vlan id 1012

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1012 VLAN1012 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1012 enet 101012 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1012 community Fa0/1

Rack1SW1#show vlan id 1034

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1034 VLAN1034 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1034 enet 101034 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1034 community Fa0/3

Rack1SW1#show vlan id 1055

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1055 VLAN1055 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1055 enet 101055 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1055 isolated Fa0/5

Rack1SW1#show interfaces fastEthernet 0/13 trunk

Port Mode Encapsulation Status Native vlan

Fa0/13 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Fa0/13 1-4094

Port Vlans allowed and active in management domain

Fa0/13 1,1000,1012,1034,1055

Port Vlans in spanning tree forwarding state and not pruned

Fa0/13 1,1000,1012,1034,1055

Verify on SW2:

Rack1SW2#show vlan id 1000

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1000 VLAN1000 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1000 enet 101000 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1012 community Fa0/2, Fa0/6

1000 1034 community Fa0/4, Fa0/6

1000 1055 isolated Fa0/6

Rack1SW2#show vlan id 1012

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1012 VLAN1012 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1012 enet 101012 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1012 community Fa0/2, Fa0/6

Rack1SW2#show vlan id 1034

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1034 VLAN1034 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1034 enet 101034 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1034 community Fa0/4, Fa0/6

Rack1SW2#show vlan id 1055

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1055 VLAN1055 active Fa0/13

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2

---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------

1055 enet 101055 1500 - - - - - 0 0

Remote SPAN VLAN

----------------

Disabled

Primary Secondary Type Ports

------- --------- ----------------- ------------------------------------------

1000 1055 isolated Fa0/6

Rack1SW2#show interface fastEthernet 0/13 trunk

Port Mode Encapsulation Status Native vlan

Fa0/13 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Fa0/13 1-4094

Port Vlans allowed and active in management domain

Fa0/13 1,1000,1012,1034,1055

Port Vlans in spanning tree forwarding state and not pruned

Fa0/13 1,1000,1012,1034,1055

Step 3:

Create a promiscuous port and configure downstream mappings. Here we add secondary VLANs for which traffic is received by this particular “P”-port. Primary VLAN is used to send traffic downstream to all “C” and “I” ports per their associations.

SW2:

!

! Promiscuous port, mapped to all secondary VLANs

!

interface FastEthernet0/6

description == R6

switchport private-vlan mapping 1000 1012,1034,1055

switchport mode private-vlan promiscuous

spanning-tree portfast

Verify the promiscuous port configuration:

Rack1SW2#show int fa 0/6 switch beg private

Administrative Mode: private-vlan promiscuous

Operational Mode: private-vlan promiscuous

Administrative Trunking Encapsulation: negotiate

Operational Trunking Encapsulation: native

Negotiation of Trunking: Off

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk private VLANs: none

Operational private-vlan:

1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)

If you need to configure an SVI on a switch to communicate with private VLAN members, you should add an interface corresponding to Primary VLAN only. Obviously that’s because all secondary VLANs are “subordinates” of primary. After an SVI has been created, you have to map the required secondary VLANs to the SVI (just like with a promiscuous port) in order to make communications possible. You may exclude some mappings from SVI interface, and limit it to communicating only with certain secondary VLANs.

SW1:

!

! SW1 SVI is mapped to all secondary VLANs

!

interface Vlan 1000

ip address 10.0.0.7 255.255.255.0

private-vlan mapping 1012,1034,1055

SW2:

!

! SW2 SVI is mapped to 1012/1034 only, so it’s cant communicate with R5

!

interface Vlan1000

ip address 10.0.0.8 255.255.255.0

private-vlan mapping 1012,1034

Now to verify the configuration, configure R1-R6 interfaces in subnet “10.0.0.0/24” and ping broadcast addresses.

Rack1R1#ping 10.0.0.255 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms

Reply to request 0 from 10.0.0.2, 4 ms

Reply to request 0 from 10.0.0.6, 4 ms

Reply to request 0 from 10.0.0.8, 4 ms

Rack1R3#ping 10.0.0.255 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 4 ms

Reply to request 0 from 10.0.0.4, 4 ms

Reply to request 0 from 10.0.0.6, 4 ms

Reply to request 0 from 10.0.0.8, 4 ms

Rack1R5#ping 10.0.0.255 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.7, 1 ms

Reply to request 0 from 10.0.0.6, 1 ms

Rack1R6#ping 10.0.0.255 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

Reply to request 0 from 10.0.0.1, 4 ms

Reply to request 0 from 10.0.0.7, 4 ms

Reply to request 0 from 10.0.0.2, 4 ms

Reply to request 0 from 10.0.0.5, 4 ms

Reply to request 0 from 10.0.0.3, 4 ms

Reply to request 0 from 10.0.0.4, 4 ms

Reply to request 0 from 10.0.0.8, 4 ms

Lastly, there is another feature, called protected port or “Private VLAN edge”. The feature is pretty basic and is available even on low-end Cisco switches. It allows isolating ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configured as protected are also configured not to receive unknown unicast (frame with destination MAC address not in switch’s MAC table) and multicast frames flooding for added security.

Example:

interface range FastEthernet 0/1 - 2

switchport mode access

switchport protected

switchport block unicast

switchport block multicast

Stateful vs. Stateless IP Filtering

Types of firewall

• Packet filters
• Stateful Inspection
• Proxys
• Dynamic
• Kernel

Packet filtering is more commonly known as a "stateless" or "static" IP filtering.

There are several advantages to using a static IP filter. It has a combination of low overhead and high throughput. Stateless IP filters are very inexpensive, and many are free. They are included with router configuration software or are included with most Open Source operating systems. Being that a static IP filter does little more than simply route traffic, it is very good for traffic management.

On the other hand, there are quite a few disadvantages to using a static IP filter, especially with regard to security. Static IP filters allow direct connections from the external network to hosts on the internal network. Static filters can become cumbersome to maintain in complex environments. Static filters are vulnerable to IP spoofing attacks, unless they have been specifically configured to prevent this. All holes in the firewall are permanent; either a hole exists or it doesn't, there is no opening and closing connections based on outside criteria. And lastly, static IP filters offer no form of authentication.

As you can see, static packet filtering does not offer enough in the way of security to be the only gateway between an internal network and the Internet. Realizing the deficiencies of static filtering, developers had to come up with more dynamic or "intelligent" solutions. Enter stateful packet filtering.

The biggest difference between simple IP filtering and stateful IP filtering is that simple IP filters have no recollection of packets that have already passed through the filter. Every packet is handled on an individual basis. Previously forwarded packets belonging to a connection have no bearing on the filter's decision to forward or drop the packet.

There are actually two classes of stateful packet filtering. The first is based on a pure packet filtering environment. The second involves application proxies. A proxy acts as an intelligent intermediary between hosts on the internal network and hosts on the external network.

Application proxy servers (a.k.a application gateways), when properly configured, are probably the most intelligent firewall or gateway that you can have. Application proxies operate at the application layer of the OSI model. This allows proxies to make much more intelligent decisions about what traffic is allowed to pass.

The tradeoff, when compared to traditional packet filtering, is the overhead of running an application gateway. An application proxy makes two connections; one to the machine on the outside of the gateway and a seperate connection to the machine on the inside of the gateway. Additionally, the application gateway processes authentication on behalf of the machine on the internal network. Therefore, the demands on the machine are significantly higher than those associated with a typical firewall.

Another problem associated with application gateways is the cost. Most application gateway solutions involve the use of expensive, proprietary software and/or hardware. Many advanced stateful packet filters are Open Source. In fact, one of the most common uses for Linux is to build a low cost stateful packet filtering firewall. Being that packet filtering with Linux is handled at the kernel level, the overhead is very low. I have heard of early Pentium class machines with minimal memory being resurrected as 100Mbps routers.

There are even projects devoted to running such systems with no hard drives. The machine is booted from a floppy that contains the kernel and all of the configuration information. Once the machine is up and running, the floppy is removed. This can be a very secure, very low cost solution for many small offices and home offices. For more information on the Linux Router Project, check here.

On the other hand, a stateful packet filter is much less resource intensive than an application gateway, while not being completely unintelligent.

Stateful packet filtering does not necessarily address all of the problems with static filtering. Authentication may still not be addressed, however stateful packet filtering does add a new dimension of security to the otherwise inadequate security of static packet filtering.

How do I configure a Cisco ASA 5510 for Internet Access

Step1: Configure a privileged level password (enable password)

By default there is no password for accessing the ASA firewall, so the first step before doing anything else is to configure a privileged level password, which will be needed to allow subsequent access to the appliance. Configure this under Configuration Mode:

ASA5510(config)# enable password mysecretpassword

Step2: Configure the public outside interface

ASA5510(config)# interface Ethernet0/0 

ASA5510(config-if)# nameif outside 

ASA5510(config-if)# security-level 0

ASA5510(config-if)# ip address 100.100.100.1 255.255.255.252

ASA5510(config-if)# no shut

Step3: Configure the trusted internal interface

ASA5510(config)# interface Ethernet0/1

ASA5510(config-if)# nameif inside 

ASA5510(config-if)# security-level 100

ASA5510(config-if)# ip address 192.168.10.1 255.255.255.0

ASA5510(config-if)# no shut

Step 4: Configure PAT on the outside interface

ASA5510(config)# global (outside) 1 interface

ASA5510(config)# nat (inside) 1 0.0.0.0 0.0.0.0

OR

ASA5510(config)# nat (inside) 1 192.168.10.0 255.255.255.0

Step 5: Configure Default Route towards the ISP (assume default gateway is 100.100.100.2)

ASA5510(config)# route outside 0.0.0.0 0.0.0.0 100.100.100.2 1

Step 6: Configure the firewall to assign internal IP and DNS address to hosts using DHCP

ASA5510(config)# dhcpd dns 200.200.200.10

ASA5510(config)# dhcpd address 192.168.10.10-192.168.10.200 inside

ASA5510(config)# dhcpd enable inside

The above basic configuration is just the beginning for making the appliance operational. There are many more configuration features that you need to implement to increase the security of your network, such as Static and Dynamic NAT, Access Control Lists to control traffic flow, DMZ zones, VPN etc.

BTW I pulled this info from another site... I was just toooo lazy to type it all out myself:-)