Have to create a guest VLAN in a catalyst switch and restrict traffic for hosts here.

[mauricio2099]

Hello, 

I have to create a guest VLAN which must not reach any other VLAN but Internet. Let's say VLAN 77 it is VLAN 77 [10.77.0.0/24] My question is: For an SVI the access-list direction should be IN or OUT in order to accomplish the goal, and why?


ip access-list extended GUEST
deny ip 10.77.0.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.77.0.0 0.0.0.255 172.16.0.0 0.15.255.255

deny ip 10.77.0.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip any any

interface vlan 77
ip access-group GUEST .......in?   .....out?

[balaji.bandi]

When it originating always IN, leaving from the router is OUT it all who is generating the traffic and connecting.

[mauricio2099]

Hi Balaji,

Thanks for replying,

sorry but I am not getting your point. 

VLAN 77 10.77.0.X is the source of communication and don't want it to reach any internal host, but Internet.

I am working on a L3switch and the ACL will be put on a VLAN interface SVI. This is not a router. 

[balaji.bandi]

Sure ACL works the same way as the Router i have suggested, this is based on the where source initiating connection

For your Case example :

VLAN 77 having source 10.77.0.X/24 network and destination other VLAN example x.x.x.x/24

access-list 100  deny ip 10.77.0.X 0.0.0.255 x.x.x.0 0.255.255

access-list 100 permit ip any any

!

interface Vlan 77

ip access-group 100 in

[mauricio2099]

Hi Balaji thanks for your reply. I see other replies that complement yours. I really appreciate your help.

[balaji.bandi]

Is that works, or you still having issue ? anything we can help ?

if resolved mark as resoltuion so other community members get benifit with your inputs.

[paul driver]

Hello

---

@mauricio2099 wrote:

I have to create a guest VLAN which must not reach any other VLAN but Internet. Let's say VLAN 77

---

Routed access-list would be applicable - the logic for an SVI is 

IN =Traffic originating from within vlan 
OUT =Traffic originating towards vlan 

IN
ip access extended vlan77

deny ip any 10.1.60.0  0.0.0.255   <--deny vlan 60
deny ip any 10.1.61.0  0.0.0.255  <--deny vlan 61
etc..
permit ip any any

int vlan 77
ip access-group vlan77 IN

OUT
ip access extended vlan77

deny ip 10.1.60.0  0.0.0.255 any  <--deny vlan 60
deny ip 10.1.61.0  0.0.0.255  any <--deny vlan 61
etc..
permit ip any any

int vlan 77
ip access-group vlan77 OUT

Additionally if the L3 switch supports it , put the guest vlan in its own VRF 
vrf guest
int vlan 77
ip forwarding vrf guest
ip route vrf guest 0.0.0.0 0.0.0.0 <wan interface> x.x.x.x global

[Richard Burts]

You could achieve your objective of limiting vlan 77 to only access the Internet and not any other vlan using access list in or using access list out. I would suggest using access list in. With access list in if the switch receives a packet from a device in vlan 77 with a destination in another vlan you deny the original packet which certainly achieves your objective. And if a device in some other vlan attempted to access something in vlan 77 the original request would get through but the response would be denied. So vlan 77 is isolated from other vlans. If you use access list out then a request from a device in vlan 77 to another vlan would get through but the response would be denied. And any request from another vlan would be denied. This does achieve your requirement but is much less effective. So my suggestion is that access list in is better for you.

[mauricio2099]

Hello Richard, Thanks for your reply and recommendation.

Thank you for elaborating on the traffic flow. I am surprised about the return traffic gets denied, the ACL works different then than a Firewall...the switch doesn't store a connections table? And return traffic would have to be explicit on the ACL sentences?

Thanks 

[Richard Burts]

This is about something that is frequently referred to as stateful inspection, where a device recognizes when a device on some interface originates a packet to some destination on another interface, and when a packet is received from that destination device is able to associate that packet with the originating device. Stateful inspection is frequently available on firewall devices and is rarely (if ever) available on switches. So yes the ACL works differently on a switch than on a firewall. And in that context yes the switch does not maintain a connection table. And yes return traffic needs to be explicit on the ACL. On a switch the processing is simplified, it looks at each individual packet separately/independently and determines for the specific source address, destination address, and protocol ports (if specified), does this match a permit statement or does it match a deny statement (including the default deny any).

[mauricio2099]

Hello Paul, thanks for your reply and for the examples.
I got a bit confused. The 'IN' example is not for traffic originated within VLAN 77, and the 'OUT' example is not for traffic looking to reach VLAN 77

"IN =Traffic originating from within vlan 
OUT =Traffic originating towards vlan "

Good point about the vrf, honestly don't know if the switch support it but will check.

[paul driver]

Hello

---

@mauricio2099 wrote:

I got a bit confused. The 'IN' example is not for traffic originated within VLAN 77, and the 'OUT' example is not for traffic looking to reach VLAN 77
"IN =Traffic originating from within vlan 
OUT =Traffic originating towards vlan "

---

An acl applied to a SVI interface ingress = "IN" will relate to any traffic originating or coming from that vlan which needs to be routed egress or outwards from that vlan.

IN
As you can see any traffic originating from vlan 77 towards vlan 60,61 will be denied but all other traffic (any) from vlan 77 to any other destinations will be allowed

ip access extended vlan77

deny ip any 10.1.60.0  0.0.0.255   <--deny vlan 60
deny ip any 10.1.61.0  0.0.0.255  <--deny vlan 61
etc..
permit ip any any

int vlan 77
ip access-group vlan77 IN

OUT
An acl applied to a SVI interface egress = "OUT" will relate to any traffic originating or coming from OUTSIDE that vlan which needs to be routed ingress or inwards towards that vlan

As you can see traffic originating from vlan 60,61 towards vlan 77 will be denied but all other traffic (any) from any other vlan to any destination in vlan 77 will be allowed

ip access extended vlan77

deny ip 10.1.60.0  0.0.0.255 any  <--deny vlan 60
deny ip 10.1.61.0  0.0.0.255  any <--deny vlan 61
etc..
permit ip any any

int vlan 77
ip access-group vlan77 OUT

[Richard Burts · Accepted solution]

I have read through this discussion again and realize that the original post really asks a simple question. It suggests this access list

ip access-list extended GUEST
deny ip 10.77.0.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.77.0.0 0.0.0.255 172.16.0.0 0.15.255.255

deny ip 10.77.0.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip any any

and asks the question "should it be applied in or out".  In the access list the source address is vlan 77, so it is vlan 77 traffic coming in to the vlan 77 interface and that means that the acl should be applied in.

[mauricio2099]

Indeed,
Thank you so much for the explanation, this was implemented so successfully. 
VLAN has internet but no local access
By the way I had to permit bootpc to a DHCP server as source and destination in order to be able to receive IP.
DNS for guest network are externals, other way I will have to permit udp 53 both ways in the ACL

The ACL looks like:

ip access-lists GUEST
permit udp any host 10.0.0.10 eq bootpc
permit udp host 10.0.0.10 any eq bootpc

deny ip 10.77.0.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.77.0.0 0.0.0.255 172.16.0.0 0.15.255.255

deny ip 10.77.0.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip any any

interface vlan 77
ip access-group GUEST in


thank you all!

[Richard Burts]

Thanks for the update. Interesting that you needed to add a permit for bootpc. I am glad that our suggestions were able to help you develop a solution that works. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.