Guest WLAN security without VLANs or Tunneling

[Dave_Moore]

When creating a Guest WLAN, it is important to protect clients from each other.  It is even more important to isolate the Guest WLAN traffic from internal networks.  Two methods for handling this are via VLANs and via Tunneling.  But if neither of these are possible (due to switch limitations) or if they are not desirable, it is possible to use ACLs to isolate the Guest WLAN while still allowing access to the Internet.  

Configuring this within cnMaestro is fairly straight forward.  Within the Guest WLAN, configure an Access Control List.  Pay careful attention to the precence order set.  The screen shot below is an example of an ACL that provides this security.

In this example:

- The Guest WLAN subnet is 192.168.15.0/24

- The DNS server is 192.168.15.1

The first two entries allow DHCP responses into the Guest WLAN.  In most cases, DHCP uses UDP, but TCP is used by some systems.  As such, it is wise to include both in an ACL

The next two entries allow traffic between the Guest WLAN subnet and the DNS server.  If more than one DNS server is used, two entries need to be added for each one.

The next three entries deny traffic to private address subnets.  It is not necessary to add all three entries if the internal subnets to be protected are not using all of these address spaces, but it is a good practice to always include all three.  This will maintain protection if they are used at a later time.  If more than one subnet is used for Guest WLANs, these three entries should be replicated for each subnet used.  This does bring up a good point.  It is important when using ACLs to isolate Guest traffic from internal traffic to define a separate Guest subnet.

The last entry allow all other TCP traffic to and from the Guest WLAN subnet.  Internet traffic is TCP-based.

There is an implicit deny for anything not specified within the Access Control List.  Anything not specified in the ACL will be denied.  It is very important to pay attention to the precedence order as decisions as to whether traffic is permitted or denied are made in order.  If a packet is allowed in precedence 2, but denied in precedence 3, that packet will be allowed.  If the order is reversed, it will be denied.  The first line that matches the packet is the one that defines what is done with it.

The attached file provides screen shots for configuring a Guest WLAN, to include using the Guest Portal in cnMaestro.

• Guest WLAN without VLANs or Tunneling.pdf (1.51 MB)

[Macreedy]

Thanks for the guide, I followed it but I'm not getting the results I'm looking for. 

I have a client that provides public Guest WiFi but they don't have an internal DNS server its all handled through the WatchGaurd firewall (which has DNS set to 8.8.8.8, 8.8.4.4) I tried putting those IPs for the the DNS portion on the ACL page, but when I test the Guset network it I'm getting a 168.254.X.X network IP and can't access anything (internally and external) through that network.

Any help would be great. The APs in question are e410s.

Thanks.

[carabina5]

Hi, 

I think you get 169.254 ip address, that's mean no dhcp assignement.

The first 2 rules in the guide is for dhcp request, and you should get a valid ip. If not, you should trace requests to dhcp.

I had same problem at the beginning, it take time to get the rules (I also restart APs sometimes).

when you get a valid IP address you should check if you can reach Internet (p.e. ping 8.8.8.8). If yes, you should check DNS.

You DNS is public, you don't need the second 2 rules, the last one is for all publics IP.

[Anandakrishnan]

Client getting IP address in 168.254.x.x range means it is failing in DHCP. Can you please check whether DHCP is allowed in the ACL ( refer first two rules in the actual post)

Regards

Anand 

[Macreedy]

Hi, Thanks for your reply. I've confirmed that DHCP has been allowed in the rule. Attached is my current ACL rules everything seems to match the tutorial.

• ACL rules.png (13.4 KB)

[Anandakrishnan]

Is your DHCP is running in the AP or outside the AP?

    if in the AP, then please run the packet capture on SSID interface ( if possible filter for DHCP) and check for DHCP discover from client and offer from the AP. Packet captuer is located at Troubleshooting section.

    If the DHCP server is not in the AP, then please make sure that there is a response for the DHCP discover, this can be verified by doing packet capture in the ethernet interface and look for DHCP offier. 

Can you please share your network topology. ( rough drawing is enough) This will help us to visualize the issue. Please add the network components in the topology. 

Suspect the the firewall could be dropping your DHCP packets(Assuming DHCP is not in the AP) . After doing a packet capture in the ethernet interface, we can confirm this. 

Regards

Anand 

[carabina5]

Hi,

this is an example that I'm using. I have default gatawey and DNS (same router) in the subnet of guest (so I don't need dns rules).

Who is your gatawey? Who is DNS?

If DNS is not in the subnet, have you configured an helper address?

Can you try a cabled device in the same vlan?

• example.gif (53.5 KB)

[Macreedy]

DHCP is running off of a watchguard firewall. The Office WiFi works properly and gets an IP address, its the Guest WiFi that doesn't get an IP from DHCP. Below is a quick drawing of the network topology. Firewall is the DHCP server and DNS is public DNS 8.8.8.8 and 8.8.4.4 thanks.

I'll get the packet capture when I get to the office.

[divakarc]

Hi Macreedy,

The reason for your clients not getting IP address, ACL rule had "port 67" allowed only in one direction, it should be allowed on both directions. I have corrected the same and DNS rules as well. Please configure ACL rules as below, where i mentioned IP addresses as per your setup.

Thanks,

Divakar

[Macreedy]

divakarc,

Your settings worked! Thank you!