Cisco 6513 ACL between VLANS

[trt]

Hi everbody,

I'm trying to build an access list between VLANS on 6513 (VTP server).  I've created a VLAN X which should be secure and inaccessible from other VLANS, but there are 10 hosts which will be accessible from anywhere in this VLAN X.

Also there will be no restriction from hosts in VLAN X to other VLANS.

I have tried 2 options but in both cases all the traffic to VLAN X is restricted, and we cannot access any host including these 10 hosts in VLAN X ;

Case 1.)

vlan access-map SECVLAN_MAP 10

match ip address SECVLAN

action forward

ip access-list extended SECVLAN

deny ip any any

permit ip any host 192.168.100.1

permit ip any host 192.168.100.2

...

permit ip any host 192.168.100.10

vlan filter SECVLAN_MAP vlan-list X

******************************

Case 2.)

ip access-list extended SECVLAN

permit ip any host 192.168.100.1

permit ip any host 192.168.100.2

...

permit ip any host 192.168.100.10

interface vlan X

ip access-group SECVLAN in

I have also added "deny ip any any" before & after permit lines, but again all the traffic towards VLAN X is blocked and there's no access to the hosts 192.168.100.1 --> 10.

Any opinions would be great help..

Thanks

Baris

[devils_advocate]

In Case 2, I think you have the ACL direction the wrong way on the SVI.

You have said #permit ip any host 192.168.100.* and then applied this Outbound to the SVI. You are saying in the access list to permit any IP traffic from any source to hosts specified in the 192.168.100.* network. This should be applied inbound to the SVI because the ACL is permitting traffic into the subnet.

On an SVI, the ACL direction is reversed. You have put 'in' which is used for traffic outbound, i.e leaving the subnet. Try putting the following:

interface vlan X

ip access-group SECVLAN out

[Karthick Murugan]

Hi Baris,

You need to create two sequence.

vlan access-map SECVLAN_MAP 10

match ip address SECVLAN

action forward

vlan access-map SECVLAN_MAP 20

match ip address UNSECURE_VLAN

action drop

ip access-list extended UNSECURE_VLAN

permit ip any any

ip access-list extended SECVLAN

permit ip any host 192.168.100.1

permit ip any host 192.168.100.2

...

permit ip any host 192.168.100.10

vlan filter SECVLAN_MAP vlan-list X

Hope it helps

Thanks & Regards,
Karthick Murugan
CCIE#39285

[Jon Marshall]

Karthik

How does your example handle the return traffic from other vlans to hosts that are not meant to be accessible ie. a remote host cannot initiate a connection to say 192.168.100.20 but 192.168.100.20 can initiate a connection to a remote host and receive the return packets.

I'm not that familiar with using VACLs so i am probably not understanding exactly how they work.

Jon

[Karthick Murugan]

Yes, the second sequence in the access-map will take care of it. If the traffic from other VLAN enters VLAN X, second sequence in the access-map will match it and drop it(action drop).

Thanks & Regards,
Karthick Murugan
CCIE#39285

[Jon Marshall]

If the traffic from other VLAN enters VLAN X, second sequence in the access-map will match it and drop it(action drop).

But what if that traffic is return traffic ?  From the original post -

I've created a VLAN X which should be secure and inaccessible from other VLANS, but there are 10 hosts which will be accessible from anywhere in this VLAN X.

Also there will be no restriction from hosts in VLAN X to other VLANS  <-- this line i interpreted to mean that any host in vlan X can access any remote vlan. But if they do won't your drop action stop the return traffic from getting back to the originating host ?

Apologies again if i am misunderstanding but i can't see how the drop action in a VACL knows whether the packet is a packet originated from a remote vlan (in which case it should be dropped) or whether it is a return packet from a connection originated by any host in vlan X (in which case it should be allowed).

Jon

[Karthick Murugan]

HI Jon,

You can modify the secure VLAN access-list like this.

ip access-list extended SECVLAN

permit ip 192.168.100.x 0.0.0.255 any

permit ip any host 192.168.100.1

permit ip any host 192.168.100.2

...

permit ip any host 192.168.100.10

Thanks & Regards,
Karthick Murugan
CCIE#39285

[Jon Marshall]

So that allows traffic from 192.168.100.0/24 to any remote host. But does the VACL keep track of the connection. That's the key point. Because when the remote host replies i can't see anything in your SECVLAN list that would allow the traffic. So it would still be dropped by your drop action.

I am not trying to prove anyone wrong here, it is more to do with my own understanding. The fundamental problem when you want to allow no access to a set of hosts one way but you want those same hosts to be allowed access the other way is that standard acls and i believed VACLs do not keep track of state. So they have no way of knowing whether the initial connection was originated from a host in the vlan or whether it was originated from a remote host. For that you need some sort of state tracking. At it's most basic there is the "established" keyword, then reflexive acls going on to firewalls.

So i guess my question is whether or not there is some additional logic in a VACL that can work out from where the packet has been originated ?

Jon

[Jon Marshall]

Baris

If i understand correctly you have a vlan say vlan 10 using 192.168.100.x addressing. 10 of those hosts can be accessed by any vlan but the rest cannot be accessed. In addition all of the 192.168.100.x hosts can access everything ie. all the other vlans.

If the above is correct you cannot use standard acls for this. The problem is return traffic. So as an example lets say you wanted to stop all vlans accessing anything other than 192.168.100.1 in vlan 10.

access-list 101 permit ip any host 192.168.100.1

access-list 101 deny ip any 192.168.100.0 0.0.0.255

int vlan 10

ip access-group 101 out  <-- it is out because it is controlling packets going to vlan 10

The above does the following -

1) it allows remote vlans to connect to 192.168.100.1

2) if 192.168.100.1 connects to a remote vlan the acl also allows the return traffic back in

3) it allows all 192.168.100.x devices to connect to remote vlans or more specifically the acl is not checked when traffic are initiated from vlan 10.

4) the acl blocks all traffic initiated from remote vlans to all 192.168.100.x hosts except 192.168.100.1

this meets almost all your requirements. But the acl also -

5) blocks return traffic to all non 192.168.100.1 hosts. If, for example, host 192.168.100.10 sends a packet to a remote device it is allowed through but when the packet is returned it is blocked by the 2nd line in the acl. This is because standard acls only see each packet in isolation ie. they do not know which side initated the connection.

No matter which direction you applied the acl or how you wrote the acl you would always run into this problem. A firewall would solve the problem because they keep track of the connection but you can also use reflexive acls which do the same sort of thing (although not as a secure as a firewall). Luckily for you the switch you are using is a 6500 and 6500s support reflexive acls (although you need to check as software versions have a habit of dropping certain features) which will allow you to get round this problem. Attached is a link to configuring reflexive acls. Have a read and if you need further help please come back -

http://www.cisco.com/en/US/customer/docs/ios/12_2/security/configuration/guide/scfreflx.html

Jon

[trt]

Hi Jon,

You got it completely true.

'vlan 10 using 192.168.100.x addressing. 10 of those hosts can be accessed by any vlan but the rest cannot be accessed. In addition all of the 192.168.100.x hosts can access everything ie. all the other vlans.'

Lets say 192.168.100.1 to 10 can be accessed from other VLANS, rest of the subnet (192.168.100.11 - 254) is blocked from outside and all 192.168.100.0/24 subnet can access everywhere including other hosts in VLAN 10.

My concern was also, what will happen when a host ie. 192.168.100.50 starts a TCP connection but the backwards traffic to this host is blocked, as there's no stateful firewall here. And in this case I can't insert a FWSM to my 6513 because it's full and have to solve this via ACLs.

As far as I understand ;

interface vlan X

ip access-group SECVLAN out  -- > here, 'out' means the traffic from VLAN 1 (& other VLANs) towards VLAN X and 'in' means vice versa, right?

Karthick, I will try the 'two sequence' solution and share the results. Thanks.

I haven't read the reflexive document yet, will also check it out, thanks btw.

Regards

Baris