Apple iOS devices can not get IP from ASA

[SIMMN]

Hey,

I have a guest WIFI setup in our DMZ and I use ASA DMZ Interface to assign IP to guest devices.

About a day ago, I started getting complains about "my ipad can not connect to Guest WIFI"...It also happens to my ipad...

I checked ASA the configuration on DMZ interface is fine and I run debug on ASA, got following:

DHCP: Server msg received, fip=ANY, fport=0 on ABC-DMZ interface

DHCPD: DHCPREQUEST received from client 011c.aba7.93d7.7e.

DHCPD: Extracting client address from the message

DHCPD: State = DHCPS_REBOOTING

DHCPD: State = DHCPS_REQUESTING

DHCPD: Client 011c.aba7.93d7.7e specified it's address 172.24.93.118

DHCPD: Client is on the correct network

DHCPD: requested address 172.24.93.118 not found

DHCPD: Sending DHCPNAK to client 011c.aba7.93d7.7e.

DHCPD: broadcasting BOOTREPLY to client 1cab.a793.d77e.

The issue only applies to Apple iOS devices. Please advise.

Thanks,

Shuai

[Antonio Simoes]

Hi,

First ASA reserves the space for the address:

DHCPD: Total # of raw options copied to outgoing DHCP message is 2.

DHCPD: creating ARP entry (10.10.15.156, bccf.cc73.6c0e).

After is not accepted from the device it clears it:

DHCPD: Binding successfully deactivated

dhcpd_destroy_binding() removing NP rule for client 10.10.15.205

Take care,

AS

[D-N]

You're on a wrong track.

As you can see from the (full) output, the "order of messages" is

Step 1: Client -> ASA = DHCPDISCOVER
Step 2: ASA -> Client = DHCPOFFER
Step 3: Client -> ASA = DHCPREQUEST
Step 4: ASA > Client = *

For a working client, Step 4 result is DHCPACK, as usual.

For a non-working client, immediately after Step 2 the ASA does

DHCPD: Binding successfully deactivated
dhcpd_destroy_binding() removing NP rule for client 10.10.15.205
DHCPD: free ddns info and binding

Which is WRONG. You don't delete a binding you just offered without any reply. Not on the spot at least.

The result is that when, at step 3, the client requests (literally accepts) the address which the ASA had just offered, the ASA cannot find the offer in it's own database (it has deleted it previously).

So step 4 is actually DHCPNAK for a non-working client, due to the way the ASA is handling things internally.

I'm guessing nobody has any clue how to deal with it.

[D-N]

I have the exact same issue. Somewhere last week, all iOS devices on our corporate network stopped getting DHCP adderesses. The symptoms are identical to the ones described above. The solution has otherwise  been working flawlessly for about two years.

WiFi access changed in spring (March) and ASA version upgraded in July. No recent admin modifications to any component within the past two weeks.

Apparently, all iOS devices stopped taking DHCP with the ASA.

[D-N]

Problem solved. Long live google search on Cisco.com.

There are several workarounds:
- Move the DHCP server function to another device like a WLC or a router.
- Downgrade the ASA to 9.1.1 or lower. 
- Moving the device to the wired network seems to not trigger the problem.
- Configure "dhcprelay timeout 60"

I configured dhcprelay timeout 60 and it's working fine now.

Kinda stupid since you can't have dhcp relay and dhcpd running on the same box.

[Antonio Simoes]

Better then.

[D-N]

Yeah, found the fix just after the last reply to you.

[SIMMN]

Okey, type in dhcprelay timeout 60 did help get ipad obtain IP however

1. we are running ASA 8.4.6

2. dhcprelay timeout command is not in running configure on ASA but in ASDM the value filled in already and no "Apply" button there.

Hope this is the real fix even it not make sense. I will wait till tomorrow to firmly say iOS devices are working.

Thanks alot for the leg work.

[D-N]

I know it makes no sense (dhcp relay and dhcpd cannot coexist), but it worked for me (~20 iOS devices). Check out bugID CSCuh79288 if you have access.

[SIMMN]

Thanks, collected.

[tneuhuber]

hello, also oberserved the bug in 8.4(7), workaround with  "dhcprelay timeout 60" is fine.

First i was thinking about an arp poisening attack, because arp cache was filled up; see below:

# sh arp | in 172.31.5

        stbmobile 172.31.5.160 e4ce.8fed.46ca 3

        stbmobile 172.31.5.159 e4ce.8fed.46ca 15

        stbmobile 172.31.5.158 e4ce.8fed.46ca 26

        stbmobile 172.31.5.157 e4ce.8fed.46ca 37

        stbmobile 172.31.5.156 e4ce.8fed.46ca 48

        stbmobile 172.31.5.155 e4ce.8fed.46ca 59

        stbmobile 172.31.5.154 e4ce.8fed.46ca 70

        stbmobile 172.31.5.153 e4ce.8fed.46ca 82

        stbmobile 172.31.5.152 e4ce.8fed.46ca 93

        stbmobile 172.31.5.151 e4ce.8fed.46ca 105