VLAN access lists

notgoing2failnotgoing2fail Member Posts: 1,138
My latest lab/blog for anyone that is interested.

BrandonTek Blog Archive VLAN Access Lists Lab#01


vacl_lab_01_a1.png

Comments

  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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.
    "There are 3 types of people in this world, those who can count and those who can't"
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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.....
  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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.
    "There are 3 types of people in this world, those who can count and those who can't"
  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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.
    "There are 3 types of people in this world, those who can count and those who can't"
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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.
  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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.
    "There are 3 types of people in this world, those who can count and those who can't"
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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?
  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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. :)
    "There are 3 types of people in this world, those who can count and those who can't"
  • Bl8ckr0uterBl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□
    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.
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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!
  • stuh84stuh84 Member Posts: 503
    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.
    Work In Progress: CCIE R&S Written

    CCIE Progress - Hours reading - 15, hours labbing - 1
  • notgoing2failnotgoing2fail Member Posts: 1,138
    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!
  • stuh84stuh84 Member Posts: 503
    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)
    Work In Progress: CCIE R&S Written

    CCIE Progress - Hours reading - 15, hours labbing - 1
  • ConstantlyLearningConstantlyLearning Member Posts: 445
    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
    "There are 3 types of people in this world, those who can count and those who can't"
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    My latest lab/blog for anyone that is interested.

    BrandonTek Blog Archive VLAN Access Lists Lab#01


    vacl_lab_01_a1.png

    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.
Sign In or Register to comment.