VLAN access lists

notgoing2fail

My latest lab/blog for anyone that is interested.

BrandonTek Blog Archive VLAN Access Lists Lab#01

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

ConstantlyLearning

Good job. Would have been nice to include a section on the logic of the VACL config. People get confused by the permit/deny statements in the ACL.

VACL's may be used in a situation where a company hosts servers for differant companies and has them in the same VLAN but doesn't have switches that support PVLAN's. Port ACL's could be used in the same situation.

notgoing2fail

ConstantlyLearning wrote: »

Good job. Would have been nice to include a section on the logic of the VACL config. People get confused by the permit/deny statements in the ACL.

VACL's may be used in a situation where a company hosts servers for differant companies and has them in the same VLAN but doesn't have switches that support PVLAN's. Port ACL's could be used in the same situation.

Ahh I was going to talk about VACL config but ended up leaving it out.

I'll go ahead and revise it, that's something people should know about I agree.....

Port ACL's...that's something to look into.....

ConstantlyLearning

notgoing2fail wrote: »

Ahh I was going to talk about VACL config but ended up leaving it out.

I'll go ahead and revise it, that's something people should know about I agree.....

Port ACL's...that's something to look into.....

I'm currently testing the best way to implement VACL's at the moment so I'd be happy to hear any thoughts you or anyone else has about them.

In relation to disparate customer servers on the same VLAN:

1) Should you configure the VACL to permit traffic to what's needed, then deny traffic to everywhere else within the VLAN and then permit traffic to everywhere else?
2) Should you configure the VACL to deny traffic to all other customer servers and then permit traffic to everywhere else?
3) Should you use PACL's in order to remove the potential of denying all traffic within the VLAN which could happen with VACL's?!

I think option 1 is the most scalable. If a new customer is introduced to the VLAN then you only need to permit traffic to what's needed for that customer.

With option 2, if a new customer was introduced to the VLAN you would have to add lines to deny traffic from their servers to all other customers servers and from all other customer servers to the new customer.

With option 3 you could put an ACL on each interface to permit traffic to where it's needed, deny traffic to everywhere else within the VLAN and permit traffic to everywhere else. I'm not sure if this is as neat as the VACL's. From my testing so far of VACL's though, I've come across the issue of forgetting to add an 'action forward' for all other traffic and locking myself out and denying a tone of traffic!!

Are VACL's a bad idea in the first place? Should you be using PVLAN's? Should you be putting disparate customer servers in separate VLAN's and allowing traffic to flow between VLAN's that needs to?

I'll put a post up on this thread over the weekend detailing some tests.

ConstantlyLearning

I'm getting progressively further away from the operational details of VACL's.

You're the only person working on implementing security within a VLAN between disparate customer servers. You understand VACL's. None of the other team members do, but they are comfortable with standard ACL's (RACL's). Do you organise a meeting to train them up on VACL's or do you just keep things simple and implement Port ACL's?

One of the reasons I don't like the PACL's is that for all servers for the same customer that are within a subnet block, you would still have to apply lines to each interface to permit traffic between them. With VACL's you could just use for example: 'permit ip 172.20.20.32 0.0.0.31 172.20.20.32 0.0.0.31' and do an 'action forward' on that.

notgoing2fail

ConstantlyLearning wrote: »

I'm currently testing the best way to implement VACL's at the moment so I'd be happy to hear any thoughts you or anyone else has about them.

In relation to disparate customer servers on the same VLAN:

1) Should you configure the VACL to permit traffic to what's needed, then deny traffic to everywhere else within the VLAN and then permit traffic to everywhere else?
2) Should you configure the VACL to deny traffic to all other customer servers and then permit traffic to everywhere else?
3) Should you use PACL's in order to remove the potential of denying all traffic within the VLAN which could happen with VACL's?!

I think option 1 is the most scalable. If a new customer is introduced to the VLAN then you only need to permit traffic to what's needed for that customer.

With option 2, if a new customer was introduced to the VLAN you would have to add lines to deny traffic from their servers to all other customers servers and from all other customer servers to the new customer.

With option 3 you could put an ACL on each interface to permit traffic to where it's needed, deny traffic to everywhere else within the VLAN and permit traffic to everywhere else. I'm not sure if this is as neat as the VACL's. From my testing so far of VACL's though, I've come across the issue of forgetting to add an 'action forward' for all other traffic and locking myself out and denying a tone of traffic!!

Are VACL's a bad idea in the first place? Should you be using PVLAN's? Should you be putting disparate customer servers in separate VLAN's and allowing traffic to flow between VLAN's that needs to?

I'll put a post up on this thread over the weekend detailing some tests.

I kinda like option 1. But it also seems like PVLAN's would be a better method.

As soon as I started reading your post, I was thinking PVLAN's all the way.

PVLAN's seems like it was designed for your scenario.

ConstantlyLearning

notgoing2fail wrote: »

I kinda like option 1. But it also seems like PVLAN's would be a better method.

As soon as I started reading your post, I was thinking PVLAN's all the way.

PVLAN's seems like it was designed for your scenario.

Money.

Currently using 2970's and getting a couple of 3560's isn't an option at the moment if the same thing can be implemented another way.

PVLAN's would be my preference.

notgoing2fail

ConstantlyLearning wrote: »

Money.

Currently using 2970's and getting a couple of 3560's isn't an option at the moment if the same thing can be implemented another way.

PVLAN's would be my preference.

Do the 2970's even support VACL's?

ConstantlyLearning

notgoing2fail wrote: »

Do the 2970's even support VACL's?

The feature navigator says so and the vlan access-map and vlan filter commands seems to be available so I'm assuming/hoping yes.

Bl8ckr0uter

Aww I didn't realise brandontek is notgoing2fail. I was like who the hell is this following me. Your blog looks very nice dude and I have it book marked. Looking forward to watching your CCNP studies.

notgoing2fail

ConstantlyLearning wrote: »

The feature navigator says so and the vlan access-map and vlan filter commands seems to be available so I'm assuming/hoping yes.

Ok because I'm pretty sure my 2960 doesn't support it. I know some L2 switches can support some L3 features.

I've always assumed that VACL's would need a L3 switch due to the fact it needs to be able to filter on the ip address....

Very interesting....

knwminus wrote: »

Aww I didn't realise brandontek is notgoing2fail. I was like who the hell is this following me. Your blog looks very nice dude and I have it book marked. Looking forward to watching your CCNP studies.

haha yeah that's me. I was waiting to see when you would notice.

Glad you like the site!

stuh84

Good stuff, looks fun, you got another subscriber and follower

I will say that if you've worked with Route Maps at any point (like from the BSCI/ROUTE syllabus) then VACLs are so similar its criminal. When I looked at VACLs, I got them straight away due to studying the BSCI. It'll work the same the other way, if you know VACLs and start looking at Route Maps, you'll see a LOT similar.

notgoing2fail

stuh84 wrote: »

Good stuff, looks fun, you got another subscriber and follower

I will say that if you've worked with Route Maps at any point (like from the BSCI/ROUTE syllabus) then VACLs are so similar its criminal. When I looked at VACLs, I got them straight away due to studying the BSCI. It'll work the same the other way, if you know VACLs and start looking at Route Maps, you'll see a LOT similar.

Thanks! I'll follow you right back...

Haven't worked with route maps yet so I'm looking forward to it. VACL's came kinda easy to me because of the CCNA Security where it taught me policy and class maps. So I was able to understand what they meant about the structure and actions such as forward and drop.

So hopefully route maps work just about the same way!

stuh84

If you've done policy maps, as far as I'm aware they are practically the same as route maps, the only difference is where they are placed (on a neighbour statement or whatever, rather than on an interface)

ConstantlyLearning

Scenario:

You have differant customer's servers connected to a switch. All devices are in a single VLAN in the subnet 172.18.0.0/24.

Currently, all devices can reach each other. You need to stop traffic from customer subnets from reaching other customer subnets. All customer servers need to be able to reach a DG, a backup server, a monitoring server and the switch. They also need to reach devices outside of the VLAN such as the internet or on the other side of a VPN.

The DG and other required devices are in subnet 172.18.0.0/28
Customer A subnet - 172.18.0.16/28
Customer B subnet - 172.18.0.32/28
Customer C subnet - 172.18.0.48/28

The way I would go about this is with the below configuration.

Note 1: If you have differant customer's servers on a VM host then traffic between them won't flow across the VLAN so won't be denied. Does anyone know how to control this traffic on ESX?
Note 2: If you have customers servers spread across multiple switches, keep things simple and just apply the same VACL config on all the switches.

ip access-list extended COMPANY_A_DENIED
permit ip 172.18.0.16 0.0.0.15 172.18.0.0 0.0.0.255
permit ip 172.18.0.0 0.0.0.255 172.18.0.16 0.0.0.15
ip access-list extended COMPANY_A_PERMITTED
permit ip 172.18.0.16 0.0.0.15 172.18.0.16 0.0.0.15
ip access-list extended COMPANY_B_DENIED
permit ip 172.18.0.32 0.0.0.15 172.18.0.0 0.0.0.255
permit ip 172.18.0.0 0.0.0.255 172.18.0.32 0.0.0.15
ip access-list extended COMPANY_B_PERMITTED
permit ip 172.18.0.32 0.0.0.15 172.18.0.32 0.0.0.15
ip access-list extended COMPANY_C_DENIED
permit ip 172.18.0.48 0.0.0.15 172.18.0.0 0.0.0.255
permit ip 172.18.0.0 0.0.0.255 172.18.0.48 0.0.0.15
ip access-list extended COMPANY_C_PERMITTED
permit ip 172.18.0.48 0.0.0.15 172.18.0.48 0.0.0.15
ip access-list extended PERMITTED_BY_ALL
permit ip 172.18.0.0 0.0.0.15 172.18.0.0 0.0.0.255
permit ip 172.18.0.0 0.0.0.255 172.18.0.0 0.0.0.15

vlan access-map VACL 10
action forward
match ip address PERMITTED_BY_ALL
vlan access-map VACL 20
action forward
match ip address COMPANY_A_PERMITTED
vlan access-map VACL 30
action forward
match ip address COMPANY_B_PERMITTED
vlan access-map VACL 40
action forward
match ip address COMPANY_C_PERMITTED
vlan access-map VACL 50
action drop
match ip address COMPANY_A_DENIED
vlan access-map VACL 60
action drop
match ip address COMPANY_B_DENIED
vlan access-map VACL 70
action drop
match ip address COMPANY_C_DENIED
vlan access-map VACL 80
action forward

vlan filter VACL vlan-list 2

Turgon

notgoing2fail wrote: »

My latest lab/blog for anyone that is interested.

BrandonTek Blog Archive VLAN Access Lists Lab#01

Nice. I found VACLs useful in a contract where I was building a colocation site. Until the firewalls I requested turned up I used them to secure the access of a couple of partner servers we were hosting for a customer on a VLAN to only allow them to access the things we wanted them to within our network. Anything to stop the attack vectors.