Solved: Guest Network access

Corneliu Paunescu · ‎02-20-2014

Hello,

Im trying to setup access for our guests to go out a specific interface/ISP

We have our main connection to our datacenter.

We also have a little SAT Receiver that we get internet from (10MB).

I want a specific vlan to go out ONLY to that SAT Receiver connection. Here is my setup:

Guest Network

vlan 216

name WIFI-Guests

SAT Receiver

interface Vlan70
ip address 192.168.151.2 255.255.255.0

interface Vlan216

description Guest WIFI

ip address 10.2.16.1 255.255.255.0

ip helper-address 10.2.1.26

Can this be done via vrf, and how? Or is there an easier way?

Thanks...

Jon Marshall · ‎02-20-2014

Just noticed that you are using an ip helper-address which means you won't be able to use a VRF effectively as your guest network needs access to the vlan with the DHCP server in it.

Assuming you want to keep DHCP for this network on the DHCP server then probably PBR is better ie.

access-list 101 permit udp any any eq bootps log

access-list 102 permit ip 10.2.16.0 0.0.0.255 any

route-map PBR permit 10

match ip address 101

route-map PBR permit 20

match ip address 102

set ip next-hop

int vlan 216

ip policy route-map PBR

note that with the above the first acl has to allow DHCP to get through to the DHCP server. Normally with PBR you would simply use just the one acl eg.

access-list 101 deny udp any any eq bootps

access-list 101 permit ip 10.2.16.0 0.0.0.255 any

but with the 3750 (and some other switches) if you use deny lines in the acl this can cause CPU issues on the switch. So a different acl is used for each PBR entry. The first PBR permit entry uses acl 101 and simply matches DHCP traffic and does nothing so it is routed normally. The second PBR permit statement uses acl 102 and matches all other traffic ie. internet and sends it to the SAT device.

Also worth saying that all traffic is sent to the SAT device but you should also apply an acl on the SVI for vlan 216 to stop traffic from vlan 216 clients to other vlans. The PBR would send this to the SAT device anyway but the SAT device might then route it back to the switch which you don't want. So your acl would look like -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.16.0 0.0.0.255

etc. for each internal subnet

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

int vlan 216

ip access-group 103 in

Hope all that makes sense. If not please come back with any questions you have.

Jon

View solution in original post

Jon Marshall · ‎02-21-2014

There are are a couple of config issues -

1) your PBR config has -

set ip next-hop 192.168.151.2

but that is the vlan 70 interface IP. You need to set it to the actual SAT device's IP address ie. it will be a 192.168.151.x address but not the vlan 70 interface IP

2) your acl 103 -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.1.0 0.0.0.255

access-list 103 deny ip 10.2.10.0 0.0.0.255

access-list 103 deny ip 10.2.14.0 0.0.0.255

access-list 103 deny ip 10.2.16.0 0.0.0.255

access-list 103 deny ip 10.2.20.0 0.0.0.255

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

the deny lines are wrong. Are these your other internal subnets ? If so using one line as an example -

access-list 103 deny ip 10.2.1.0 0.0.0.255

should be

access-list 103 deny ip 10.2.16.0 0.0.0.255 10.2.1.0 0.0.0.255

etc.

so for each line you need a source subnet ie. 10.2.16.0/24 and a destination subnet ie. your internal subnets. But if they are all 10.2.x.x subnets then you could just replace all your deny lines with one line so your acl would look like -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.16.0 0.0.0.255 10.2.0.0 0.0.255.255

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

you deny 10.2.16.0/24 first because you need to stop it communicating with other internal subnets. Then you permit it to talk to any other IP ie. internet. If you just had a permit line then the 10.2.16.0/24 network would be able to talk to everything ie. internal subnets and internet.

Note if you don't care whether or not 10.2.16.0/24 can talk to internal subnets then you don't need this acl.

Jon

View solution in original post

Jon Marshall · ‎02-20-2014

It could be done with a VRF although it depends on whether you need the guest access network to communicate with the other internal vlans.

If not VRFs would be a good solution.

The alternative is to use PBR to force traffic for the guest network to go to the SAT device.

Whether you can do either depends on your switch model and as important the feature set of the IOS.

So what is the switch and feature set (a "sh ver" will show you the feature set)

Jon

Corneliu Paunescu · ‎02-20-2014

The Switch is a 3750x

The guest network should ONLY access the SAT device network, nothing else.

BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(53r)SE2, RELEASE SOFTWARE (fc1)

License Level: ipservices

License Type: Permanent

Next reload license Level: ipservices License Level: ipservices
License Type: Permanent
Next reload license Level: ipservices

Jon Marshall · ‎02-20-2014

The good news is you have the right feature set to use both.

So if -

1) the guest network should only be able to get to the SAT device and no other subnet (which you have confirmed)

and

2) nothing else uses the SAT device except the guest network

then i think a VRF is the answer. So your config would look like -

ip vrf

rd <--- you need a ":" value here although the RD is not actually used as it is with MPLS

int vlan 216

ip vrf forwarding

ip route vrf 0.0.0.0 0.0.0.0

Couple of things -

1) when you apply the "ip vrf forwarding ..." under the interface you may need to reapply the IP. It definitely does this with full MPLS and from memory i think it does it with VRF-Lite as well.

2) i assume the SAT device is in vlan 216 hence the default route pointing directly to the SAT device as a next hop

see this link for full details -

http://www.networkers-online.com/blog/2009/02/vrf-lite/

Jon

Jon Marshall · ‎02-20-2014

Apologies made a mistake here -

2) the SAT device shouldn't be in the same vlan unless you are going to make that the default gateway for the clients in which case you do not need the default route i added to the config.

If the SAT device is in another vlan then that vlan should only have the SAT device in it (preferably) and the SVI for that vlan should also be placed into the same VRF. Then you would need the default route.

To be honest if only the guest network is going to use the SAT device then it would be easier to put it into vlan 216 and make it the default gateway for the clients.

Jon

Corneliu Paunescu · ‎02-20-2014

Wait,

What do you mean put the SAT device in the vlan216 and make it default gateway?

My SAT is in Vlan71

My Guests are in Vlan216

Each one has their own gateways, of course.

What what you mean by putting the SAT in vlan216? I didnt understand that part, but it sounds VERY interesting.

Thanks for all the options. I will set that up tomorrow and test it over the weekend. Really appreciate the help.

Jon Marshall · ‎02-20-2014

If the only the guest network uses the SAT device ie. nothing else needs to use the SAT device then it may be easier to put it into vlan 216 and give it an IP from that subnet and then set the clients in vlan 216 to use the SAT device as their default gateway.

If you did this then there is no need for a default route in the VRF.

If you leave it in vlan 71 (or vlan 70, your first post suggests vlan 70) is there anything else in vlan 71. The issue is ideally you want to keep the vlan 216 traffic away from anything else. If vlan 70/71 only contained the SAT device then you could just put the SVI for vlan 70/71 into the same VRF.

But if there are other things in the SAT vlan then you cannot put that vlan into the VRF because the other devices would then be cut off from the rest of the network and the guest network would have access to those devices unless you used an acl on the SVI.

You can do route leaking between the VRF and the global routing table but it would be a lot easier if the SAT device was only for the guest network.

So does anything else use the SAT device other than the guest network ?

Jon

Jon Marshall · ‎02-20-2014

Just noticed that you are using an ip helper-address which means you won't be able to use a VRF effectively as your guest network needs access to the vlan with the DHCP server in it.

Assuming you want to keep DHCP for this network on the DHCP server then probably PBR is better ie.

access-list 101 permit udp any any eq bootps log

access-list 102 permit ip 10.2.16.0 0.0.0.255 any

route-map PBR permit 10

match ip address 101

route-map PBR permit 20

match ip address 102

set ip next-hop

int vlan 216

ip policy route-map PBR

note that with the above the first acl has to allow DHCP to get through to the DHCP server. Normally with PBR you would simply use just the one acl eg.

access-list 101 deny udp any any eq bootps

access-list 101 permit ip 10.2.16.0 0.0.0.255 any

but with the 3750 (and some other switches) if you use deny lines in the acl this can cause CPU issues on the switch. So a different acl is used for each PBR entry. The first PBR permit entry uses acl 101 and simply matches DHCP traffic and does nothing so it is routed normally. The second PBR permit statement uses acl 102 and matches all other traffic ie. internet and sends it to the SAT device.

Also worth saying that all traffic is sent to the SAT device but you should also apply an acl on the SVI for vlan 216 to stop traffic from vlan 216 clients to other vlans. The PBR would send this to the SAT device anyway but the SAT device might then route it back to the switch which you don't want. So your acl would look like -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.16.0 0.0.0.255

etc. for each internal subnet

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

int vlan 216

ip access-group 103 in

Hope all that makes sense. If not please come back with any questions you have.

Jon

Corneliu Paunescu · ‎02-21-2014

Thank you Jon, this really helped me a LOT.

This is what I got so far:

interface Vlan216
description Guest WIFI
ip address 10.2.16.1 255.255.255.0
ip helper-address 10.2.1.26

interface Vlan70
description Guest SAT
ip address 192.168.151.2 255.255.255.0
end

access-list 101 permit udp any any eq bootps log

access-list 102 permit ip 10.2.16.0 0.0.0.255 any

route-map PBR permit 10
match ip address 101

route-map PBR permit 20
match ip address 102
set ip next-hop 192.168.151.2

int vlan 216
ip policy route-map PBR

access-list 103 permit udp any any eq bootps
access-list 103 deny ip 10.2.1.0 0.0.0.255
access-list 103 deny ip 10.2.10.0 0.0.0.255
access-list 103 deny ip 10.2.14.0 0.0.0.255
access-list 103 deny ip 10.2.16.0 0.0.0.255
access-list 103 deny ip 10.2.20.0 0.0.0.255
access-list 103 permit ip 10.2.16.0 0.0.0.255 any

int vlan 216
ip access-group 103 in

One simple question, which I think I might know the answer, but I want to double check my way of thinking, VS what you put together for me, which again I appreciate.

In ACL103, why did you deny vlan216, then permitted again at the end?

Is there a specific reason for that?

Again thanks for your help. I would never have thought that I could not do VRF due to the IP Helper, until after I probabl would have spent hours on this project lol...

Jon Marshall · ‎02-21-2014

There are are a couple of config issues -

1) your PBR config has -

set ip next-hop 192.168.151.2

but that is the vlan 70 interface IP. You need to set it to the actual SAT device's IP address ie. it will be a 192.168.151.x address but not the vlan 70 interface IP

2) your acl 103 -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.1.0 0.0.0.255

access-list 103 deny ip 10.2.10.0 0.0.0.255

access-list 103 deny ip 10.2.14.0 0.0.0.255

access-list 103 deny ip 10.2.16.0 0.0.0.255

access-list 103 deny ip 10.2.20.0 0.0.0.255

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

the deny lines are wrong. Are these your other internal subnets ? If so using one line as an example -

access-list 103 deny ip 10.2.1.0 0.0.0.255

should be

access-list 103 deny ip 10.2.16.0 0.0.0.255 10.2.1.0 0.0.0.255

etc.

so for each line you need a source subnet ie. 10.2.16.0/24 and a destination subnet ie. your internal subnets. But if they are all 10.2.x.x subnets then you could just replace all your deny lines with one line so your acl would look like -

access-list 103 permit udp any any eq bootps

access-list 103 deny ip 10.2.16.0 0.0.0.255 10.2.0.0 0.0.255.255

access-list 103 permit ip 10.2.16.0 0.0.0.255 any

you deny 10.2.16.0/24 first because you need to stop it communicating with other internal subnets. Then you permit it to talk to any other IP ie. internet. If you just had a permit line then the 10.2.16.0/24 network would be able to talk to everything ie. internal subnets and internet.

Note if you don't care whether or not 10.2.16.0/24 can talk to internal subnets then you don't need this acl.

Jon

Corneliu Paunescu · ‎02-21-2014

Thank you Jon. Yes I do care if the Guests can talk with the internal network, so I will need the ACL. I dont want them to have access to the local subnets, just out to the NET.

Thanks again, I will implement this over the weekend and see what happens.

Thanks very much....

Corneliu Paunescu · ‎02-21-2014

I got a question.

Why I cannot use vrf? Is it because of the IP Helper? Ive seen some setup at a few offices where vrf interfaces HAD IP Helper.
Is my case different?

Thanks....

Jon Marshall · ‎02-21-2014

You could use VRFs but you would need to do route leaking between the VRF and the global routing table because your SAT device is in a different vlan and there are other devices in that vlan so you cannot just add that vlan to the VRF.

In terms of DHCP i have never tested this but i assume if part of the DHCP negotiation is unicast then you would also need to do route leaking for this as well.

Like i say it can be done if you want but i just thought PBR would be easier.

Jon