Solved: ip access-list : for guest wifi

mwilde · ‎11-26-2018

Hi, networking is not my speciality, hence I'm struggling to get this to work.
I want to create a VLAN for guest wifi access. I don't want anyone on this VLAN to access anything other than the internet.

I am using a pair of Nexus 3548.

I have created a interface VLAN on the first switch

interface Vlan50
  description guest_wifi
  no shutdown
  ip access-group guest_wifi in
  ip access-group guest_wifi out
  ip address 192.168.10.1/24
  ip dhcp relay address 10.100.64.180
  ip dhcp relay address 10.100.64.181
  vrrp 50
    priority 110
    address 192.168.10.1
    no shutdown

And similar on the second switch

interface Vlan50
  description guest_wifi
  no shutdown
  ip access-group guest_wifi in
  ip access-group guest_wifi out
  ip address 192.168.10.2/24
  ip dhcp relay address 10.100.64.180 
  ip dhcp relay address 10.100.64.181 
  vrrp 50
    address 192.168.10.1 
    no shutdown

I then have created the access list on both like this

ip access-list guest_wifi
  10 deny ip any 10.0.0.0/8
  20 deny ip any 172.0.0.0/8
  30 permit ip any any

I have tried all sorts of different rules in the access-list. I have changed the acces-group statement from in and out...

It just doesnt seem to work. Can someone please point me in the direction of what is wrong?

I want the clients to see 10.100.64.180 and 10.100.64.181 for DHCP, but then I just want to give http, https and DNS access. I have tried this....

ip access-list guest_wifi
  10 permit udp any any eq domain
  20 permit tcp any any eq www
  30 permit tcp any any eq 443
  40 deny ip any any

Seb Rupik · ‎11-26-2018

I which case I would move towards the VRF solution and use the firewall for all of your filtering.

There is something not right with the Nexus.

View solution in original post

mwilde · ‎11-27-2018

Seb - thank you for your help yesterday. I have been in contact with Cisco all day today. We eventually got to the bottom of it.

There is a bug on the version of IOS on the switch which means if you have a dhcp relay on a interface the ACL does not apply.

N3500 RACL not hit when configured with DHCP relay on same intf

CSCuy63407

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy63407/?reffering_site=dumpcr

Description

Symptom:Routed ACL not filtering traffic when applied on inbound with DHCP relay configured on the interface.
No ACL hits are observed and is not applied at all.

Conditions:DHCP relay configured on the same interface where RACL-Inbound is being applied on N3500 series switches either in Normal or WARP mode.

Workaround:Use Outbound RACL to filter specified traffic based on traffic flow if switch is running in Normal forwarding mode.
No workaround for WARP mode, only option is to remove DHCP relay and resort to a local DHCP server in the subnet/VLAN.

View solution in original post

Seb Rupik · ‎11-26-2018

Since you are usig extended ACLs with destination ports specified, you need to be careful about which direction you apply it. In your case it should be inbound.
I've also include an ACE to cover VRRP traffic.

The following should work:

!
ip access-list guest_wifi
  5 permit udp 192.168.10.0 0.0.0.255 host 10.100.64.180 eq 67
  6 permit udp 192.168.10.0 0.0.0.255 host 10.100.64.181 eq 67
  7 permit 112 any host 224.0.0.18
  10 permit udp 192.168.10.0 0.0.0.255 any eq domain
  20 permit tcp 192.168.10.0 0.0.0.255 any eq www
  30 permit tcp 192.168.10.0 0.0.0.255 any eq 443
  40 deny ip any any
!
int vlan50
  ip access-group guest_wifi in
  no ip access-group guest_wifi out
!

Cheers,
Seb.

mwilde · ‎11-26-2018

Hi Seb.

Thank you for your help. I changed my rules to be like yours, but I couldnt get an IP address from DHCP.
I assume this is becuase of

5 permit udp 192.168.10.0 0.0.0.255 host 10.100.64.180 eq 67
  6 permit udp 192.168.10.0 0.0.0.255 host 10.100.64.181 eq 67

So I change it to

5 permit udp any 10.100.64.180/32 eq bootps
6 permit udp any 10.100.64.181/32 eq bootps

I can get an IP now. However I still cannot get internet access.

Looking at my firewall monitor I can see that the traffic is getting to it from that IP address, but nothing appears on the laptop - it just says "www.google.com took too long to respond."

I have added another laptop into the firewall rule, but on my normal VLAN and the firewall rule works and I have internet access.

Do I need to allow something else on the VLAN access-list?

Seb Rupik · ‎11-26-2018

Just to clarify your point about the firewall monitor, are you saying it is seeing the return traffic from google, or it is only seeing traffic destined to google from your guest wifi subnet?

Cheers,

Seb.

mwilde · ‎11-26-2018

The firewall is co-managed and I have limited access to what I can see. I assume you are asking, to see if there is a route back to that subnet?

I had setup a temp subnet to do my testing as to not mess with the live system.

I have now changed the rule to the real subnet, as you can get internet access on it.

So the rule now is

ip access-list guest_wifi
  5 permit udp any 10.100.64.180/32 eq bootps
  6 permit udp any 10.100.64.181/32 eq bootps
  7 permit 112 any 224.0.0.18/32
  10 permit udp 10.100.92.0/22 any eq domain
  20 permit tcp 10.100.92.0/22 any eq www
  30 permit tcp 10.100.92.0/22 any eq 443
  40 deny ip any any

and

interface Vlan60
  description byod_lan
  no shutdown
  ip access-group guest_wifi in
  ip address 10.100.92.2/22
  ip dhcp relay address 10.100.64.180 
  ip dhcp relay address 10.100.64.181 
  ip dhcp relay address 10.100.64.188 
  vrrp 60
    address 10.100.92.1 
    no shutdown

I can get internet acces. And its hitting the rule I want it to on the firewall. I have create one rule for allow, and one for deny. It appears to be working.

However... I can still ping and access internal servers. I can access 10.100.64.188 (as an example)

Seb Rupik · ‎11-26-2018

hm I can't see how IP packets are reaching 10.100.64.188 with that ACL in place. As a sanity check, if you try the following:

!
ip access-list BLOCK-ALL
  10 deny ip any any
!
int vlan60
  ip access-group BLOCK-ALL in
!

... is 10.100.64.188 still reachable?

As a side note, since this traffic is passing through a firewall and you want to prevent BYOD users from accessing the rest of your network, have you considered putting the BYOD interfaces into a separate VRF?

This would require you to configure new layer3 links to the firewall from the VRF.

cheers,

Seb.

mwilde · ‎11-26-2018

I added that rule and it made no diffrence. I could still get internet access and could still access the internet.

mwilde · ‎11-26-2018

To test I have a laptop which is connected into a stack of switches in the server room, which then goes into the two core switches.

I am making the changes on the core switches - not on the stack.

Do I need to do it on the stack of switches then?

Seb Rupik · ‎11-26-2018

To test, connect the laptop to the switchport (access vlan 60) and ensure the laptops default gateway is 10.100.92.1 . With this configuration does the deny ip any any still allow the traffic through??

mwilde · ‎11-26-2018

Ok - the laptop is directly patched into into the coreswitch.
Its in Eth1/2 - please ignore the description.

interface Ethernet1/2
  speed 1000
  description ***Unused_Ports***
  switchport access vlan 60
  no shutdown

I have a statement simply says

vlan 60
  name BYOD

Then

interface Vlan60
  description byod_lan
  no shutdown
  ip access-group BLOCK-ALL in
  ip address 10.100.92.1/22
  ip dhcp relay address 10.100.64.180 
  ip dhcp relay address 10.100.64.181 
  ip dhcp relay address 10.100.64.188 
  vrrp 60
    priority 110
    address 10.100.92.1 
    no shutdown

ip access-list BLOCK-ALL
  10 deny ip any any

I really appreciate all this help you are giving me.

Seb Rupik · ‎11-26-2018

OK, so the switch config looks good. Can you confirm that the laptop is using the VLAN60 VRRP VIP (10.100.92.1) as its default gateway?

...and if it is, the deny ip any any is having no effect??

mwilde · ‎11-26-2018

yes it is.
10.100.92.125
255.255.252.0

10.100.92.1

Its still having no effect. I can ping and browse the web

mwilde · ‎11-26-2018

I dont know if this is a valid test....

interface Ethernet1/2
  speed 1000
  description ***Unused_Ports***
  switchport access vlan 60
  ip access-group BLOCK-ALL in
  no shutdown

ip access-list BLOCK-ALL
  10 deny ip any any

I had a constant ping on an internal server. I shutdown the interface and the ping timed out - to ensure it was the right int - which I knew it was.

I then added the ip access-group command. Just to be sure I shutdown the int and started it again. I can still ping stuff on the network and can access the internet.

Seb Rupik · ‎11-26-2018

eth1/2 is configured as a layer2 switchport, applying a layer3 ACL on it will have no effect.

At this stage I am a bit stumped as to why the ACL is not working correctly on the VLAN60 SVIs.

One piece of mis-configuration I have noticed in your config which should be corrected and may warrant a re-test. The VLAN SVI IP address should not be the same as the VRRP VIP. You should have the following:

! router01
!
int vlan60
  ip address 10.100.92.2/22
  !
  vrrp 60
    address 10.100.92.1
!

! router02
!
int vlan60
  ip address 10.100.92.3/22
  !
  vrrp 60
    address 10.100.92.1
!

cheers,

Seb.

mwilde · ‎11-26-2018

interface Vlan60
  description byod_lan
  no shutdown
  ip access-group BLOCK-ALL in
  ip address 10.100.92.2/22
  ip dhcp relay address 10.100.64.180 
  ip dhcp relay address 10.100.64.181 
  ip dhcp relay address 10.100.64.188 
  vrrp 60
    priority 110
    address 10.100.92.1 
    no shutdown

interface Vlan60
  description byod_lan
  no shutdown
  ip access-group BLOCK-ALL in
  ip address 10.100.92.3/22
  ip dhcp relay address 10.100.64.180 
  ip dhcp relay address 10.100.64.181 
  ip dhcp relay address 10.100.64.188 
  vrrp 60
    address 10.100.92.1 
    no shutdown

Still no diffrence unfortunately.