Security

Hi!

does anyone knows have to avoid DHCP starvation on Guest Networks? people how dont have access to the guest network see an open SSID an try to connect, the captive portal opens but because anyone is givin them access they leave the "Association Open" .  On the controller they are on logon role, wich is ok. But this kind of users are consuming all the ips availables.  The problem is when a legitime user tries to connect there is no free ip available.

A shortcout could be to configure a bigger networks, but the issue is that we will need bigger and bigger networks. 

Does anyone have a solution, kind of " if the user is on logon role more than 60 minutes the controller can kick the user"

thanks :)

Hi Cmedranosim,

You assumption is correct!

An captive poral works based on an open SSID with only a DNS redirection. Yes clients passing by will automatic connecting to a open SSID. Normally seen on the "guest" SSID because this should the only SSID thats allowed to be open or open-captiveportal.

Couple of things you can do to prevent this;

- Shorten the DHCP lease time, a half hour/one hour or so, not 7 days ;)

- Or increase the DHCP scope

- Or use more smaller subnets with "named vlans" / vlan pooling.

- Stop using een open SSID and use PSK encryption, or PSK combined with an captiveportal.

Hope this helps you!

Caveat: This is not official Aruba guidance, or even a hard and fast rule - it's just a starting point... Because you have to start somewhere. This just usually gets me pretty close to where I need to be. 

As a general starting point for scoping DHCP, I start with two rules of thumb, and then refine as needed based on specific requirements within that environment. 

1) Lease time half of average dwell time:

If your guest environment is such that the typical amount of time someone spends on it is 90 minutes (such as a coffee shop), set your lease time to 45 minutes. If they're typically there for 24 hours (such as a hotel), set it to 12 hours. This data can be obtained by monitoring the environment. 

2) Scope at least 2x your peak device count

If your peak device count is 1200, set your scope to at leat 2400 addresses. Generally along subnet boundaries. If you're segmenting things out into multiple L2/L3 networks, you'll want to do your device counts and dwell time based on each network segment rather than in the aggregate. In a university setting, for example, you'll see different client dwell times/counts in the dorms (days) than you will in classroom buildings (a couple of hours) or conference spaces (several hours/a few days)

If your lease time:dwell time ratio moves off of 1:2, then adjust your scope size accordingly - halving your lease time should lead to doubling your scope. 

Why do I do it this way?

Here's how the DHCP renewal process works (excerpted from ServerBrain)

A DHCP client automatically attempts to renew its lease as soon as 50 percent of the lease duration has expired. The DHCP client will also attempt to renew its IP address lease each time that the computer restarts. To attempt a lease renewal, the DHCP client sends a DHCPREQUEST packet directly to the DHCP server from which the client obtained the lease.

If the DHCP server is available, it renews the lease and sends the client a DHCPACK packet with the new lease duration and any updated configuration parameters. The client updates its configuration when it receives the acknowledgment. If the DHCP server is unavailable, the client continues to use its current configuration parameters.

If the DHCP client fails to renew its lease the first time, then the DHCP client broadcasts a DHCPDISCOVER packet to update its address lease when 87.5 percent of the current lease duration expires. At this stage, the DHCP client accepts a lease that any DHCP server has issued.

The DHCP server still hangs on to expired leases for a time period (which varies based on the server configuration, I believe the default is usually one additional lease period) before they are scavenged and available for re-issue. If you're in a high-turnover environment such as an airport or a shopping mall, you want those addresses reusable relatively soon after it's determined the client is not returning, otherwise large amounts of your scope will be consumed by leases that are no longer needed. 

One caveat is that if your lease time is too short, it will generate additional traffic at renewal time (just like at the DMV!), so be sure to size the DHCP server hardware accordingly.  

It's also worth keeping an eye on your scope usage and make sure it doesn't exhaust itself as your usage patterns may change over time. If you find yourself getting closer to exhausting the pool, then you'll probably want to expand it or reduce the lease time.

If you're monitoring your DHCP traffic for NAK frames, make sure you're differentiating between why the server sent a NAK - guest devices will often first request a renewal of the last DHCP address they had on that interface (even if it was on an entirely different network) which will cause your DHCP server to issue a NAK if the requested renewal is for an address in an entirely different subnet, or is for an address in the current subnet that is already in use. The NAKs you're really interested in are the ones related to scope exhaustion or the server receiving multiple requests from a single client. The latter are indicative that you might have a problem on the network, while the former is just noise. 

Hi,

(Haha) it happens.

I would suggest you use 2 VLANs, one for logon-role and another for the post-auth role. (Most probably "guest-role"!!)

Reduce the Lease period for the logon role to 1hour or 30mins, this way you can keep your authenticated users and non-authenticated users segregated.

logon-role VLAN's IP resource can be limited or extended based on the requirement, by changing the subnet on the DHCP server

.

If you want you can flush the logon role VLAN on the DHCP server, no body would complain! ;)

-Jeeva Selvakumar