VLAN Security – VLAN Access Control List’s (VACL)

I’ve been studying to renew my CCNP as of recently, and I decided to create a refresher blog post about the implementation of VACLs.

VLAN Access Control Lists (VACLs) can be used to implement Access Control at both Layer 2 and Layer 3. Typically, access lists are applied to ingress or egress traffic on a routed, L3 interface. VACL’s allow you to apply the filtering to all packets, regardless of direction.

VACL’s are created and applied in a similar manner to route-maps and policy-based routing, in the sense that you create a VLAN access-map, and then apply the VLAN access-maps to VLAN’s with a filter statement. Lets see an example.

I have pre-created VLAN 123 with an L3 interface address of 10.123.123.1/24. I have joined a port to this VLAN, and connected a PC with an IP address of 10.123.123.124/24.

IP-based VACL

For a Layer 3, IP-based VACL, we must first create a regular ACL. This ACL will either contain IP’s to permit, or IP’s to block. Remember that by default, an implicit ‘deny all’ is in place, so unless you explicitly allow, the packets will be denied.  The implicit ‘deny all’ can be counteracted with an explicit ‘allow all’ at the tail end of the ACL. In this case, only specifically denied traffic will be denied.

Create the Access List
vacl_1  

Create the VLAN Access Map
vacl_2

Confirm the VLAN Access Map Configuration
vacl_4

Apply the the VLAN Access Map to specified VLAN(s)

Confirm the Application of the VLAN Access Map
vacl_5

Lets test the configuration.  We have specifically allowed only 10.123.123.123 to be able to communicate on the VLAN.

With the IP address set to 10.123.123.123/24, we can successfully ping the L3 interface of the VLAN.
vacl_6

With the IP address set to 10.123.123.124/24, we cannot.
vacl_7

We now have a functional implementation of a Layer 3 VLAN Access Control List!  Now, lets delve into how similar functionality can be achieved at Layer 2.

MAC-based VACL

Layer 2 filtering simply involves substituting MAC Access Control Lists for IP Access Control Lists.  MAC ACL’s are very similar to IP ACL’s, and extended MAC ACL’s can even make use of wildcard masks.  Wildcard masks might be used if you wanted to restrict traffic to a certain vendor’s MAC OUI. Under typical circumstances, the first 24 bits of a MAC address are known as an Organizationally Unique Identifier, and are assigned to vendors by the IEEE under ISO/IEC 8802 standards.  Anyway, on to the example.

First, clear out the existing VLAN access map with a no vlan access-map FILTER_NAME.

We need to make a MAC ACL.  In this case, I am specifically denying my laptop’s MAC address.  I have blurted out part of the MAC for security purposes.  I didn’t, but you’d probably want to add an allow any any statement if you only want to block specific MAC addresses.

Create the MAC Access Control List
vacl_8

Confirm the MAC ACL Creation

vacl_9

Create the VLAN Access Map
vacl_10

Confirm Application of VLAN Access-Map
vacl_12

vacl_13

Confirm Functionality of MAC-based VLAN Access-Map

vacl_7

There we have it!  We have successfully implemented both IP-based and MAC-based VACL’s.

UPDATE: Branch Office Connections – GRE over IPSec VPN

022512_2257_BranchOffic1.png

It has been almost 3 years since I wrote Branch Office Connections – GRE over IPSec VPN!  For those of you who are familiar with Cisco certification, that means time to renew!  Anyway, I’m coming back now and looking at this lab, I noticed that we are preferring the serial link for traffic!  In this day and age, the serial link would likely be the fallback, and a faster, cheaper GRE/IPSEC VPN would likely be the preferable route!  Anyway, to accomplish this, we need to look at EIGRP and its determination of the best route.  EIGRP uses bandwidth, delay, reliability, load, and MTU. Essentially, bandwidth and delay are what we are going to play with here; hopefully your ISP is reliable, and not over-provisioned.  Manipulation of bandwidth and delay will affect the feasible route’s metric, and in turn affect which route EIGRP will prefer.  Manipulation of these values will not affect the actual throughput or latency on the link, they are purely for manipulating routing decisions, as we are doing here.

tun0_bw

When I fired this lab back up, I found that the default bandwidth on the Tunnel interface was 9kbps! Actually, I used bandwidth inherit incorrectly; this configuration does not cause Tunnel0 to inherit the bandwidth of the FastEthernet interface.  Bandwidth inherit would be used on sub-interfaces, to inherit the bandwidth of the primary interface. A tunnel is not a sub-interface of the transmitting/receiving PHY’s. Anyway, we should make sure we declare a higher bandwidth and lower delay than the Serial backup on these Tunnel interfaces.

Cisco uses tens of microseconds as unit of measure for delay. 1 millisecond = 1000 microseconds, so 1 millisecond = 100 tens of microseconds.  So lets say you have a 50 millisecond ping between your branch office and HQ, you would use a delay value of 5000.  FastEthernet’s default bandwidth is 100,000kbps, so we’ll use that for our tunnel bandwidth.

On R4:

R4_bw_delay

R4’s Routing Table – Before & After

Before

R4_before

After

R4_after

At this point, our Branch Office is routing egress traffic destined for the Enterprise Core over the GRE/IPSEC tunnel.  Lets go ahead and see what the routing table looks like on the other side, on R2.

R2_before

Aha!  The Enterprise Core is still routing traffic destined for the Branch Office over the Serial link.  Why is this? Well, R2 still doesn’t realize that the Tunnel interface has a higher bandwidth and lower latency.  Let’s go ahead and fix that.

R2_bw_delay

After

R2_after

Bingo.  We’ve fixed it all up.  It is critical that any interface metric manipulations are performed on both sides of the link, otherwise the result is a non-symmetrical traffic pattern, which may result in confusion and difficult troubleshooting weeks, months, or years down the road.