Re: Apple iOS devices can not get IP from ASA

SIMMN · ‎08-29-2013

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

Julio Carvajal · ‎08-29-2013

Can you post the DHCP configuration?

Also share the

show dhcpd state

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

SIMMN · ‎08-30-2013

What I found is, the issue went away middle of the day and then pop up the next morning. It seems like there is some timer not be liked on iOS devices, but I have reduced the lease time to 4 hours...

fw-pri# sh run | i dhcp

dhcpd dns 8.8.8.8 4.4.2.2

dhcpd lease 14400

dhcpd address 172.24.93.50-172.24.93.250 DMZ-INT

dhcpd dns 172.24.93.6 8.8.8.8 interface DMZ-INT

dhcpd option 3 ip 172.24.93.254 interface DMZ-INT

dhcpd enable DMZ-INT

fw-pri# SH dhcpd state

Context Configured as DHCP Server

Interface INTERNET, Configured for DHCP SERVER

Interface Trusted, Not Configured for DHCP

Interface Internal, Not Configured for DHCP

Interface DMZ-INT, Configured for DHCP SERVER

Interface Management, Not Configured for DHCP

fw-pri# sh processes | i dhcp

Mwe 0x0820b5c9 0xad535d0c 0x0a39b670 20311 0xad531ee0 7060/16384 dhcp_daemon

fw-pri# sh processes | i DHCPD

Mwe 0x082092a1 0xad52da14 0x0a39b670 2200 0xad529b58 15048/16384 DHCPD Timer

Julio Carvajal · ‎09-01-2013

Any difference after changing the leased time?

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

SIMMN · ‎09-01-2013

Not really...

turbo_engine26 · ‎09-01-2013

Hi,

Take a look at this:

http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html

http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address-workaround.html

Regards,

AM

SIMMN · ‎09-01-2013

Thanks for the link.

It helps understand why it might happen to iOS devices only but it is still a mystery why it suddenly started after working fine for last 1 and half years?

SIMMN · ‎09-03-2013

What we found so far:power cycle the device OR forget network and power cycle fixed the issue...

turbo_engine26 · ‎09-03-2013

Hi,

Yes, that was mentioned in the links that i posted. I strongly believe that this is a bug in certain iOS software versions. Also, the links i provided you is a strong proof that it is a global issue in Apple iOS devices (Not ASA). Your DHCP config is correct. This is another link to consider from Apple site itself:

https://discussions.apple.com/thread/3681645?start=0&tstart=0

Therefore, i would recommend to spend more time to read them and search for a workaround.

Regards,

AM

Antonio Simoes · ‎09-03-2013

Hi,

Hey do you have ip dhcp binding active?

If yes, may you must to add the adrresses of your devices.

If dont, run a packet sniffer to see if the asa sends every dhcp packet correctly to the device and see also if it respondes correctly.

I also sugest you to run

debug ip dhcp server {events | packets | linkage}

Enables debugging on the DHCP Server.

-AS

SIMMN · ‎09-03-2013

I think you mean "sh dhcpd binding all" not the ip dhcp binding active, right? My ASA doesnot have the command. I do have bindings though.

I did debug and the out put I got were like:

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.

P.S, I think you are talking about IOS router but I am talking about ASA...

Antonio Simoes · ‎09-03-2013

Hi,

The messages and they order ar strange.

Can you plz do the debugging with other device and post the info here plz.

-AS

D-N · ‎09-04-2013

It's not from the original system, but one exibiting the exact same sympyoms:

1. Client with problem (one of our many iOS devices)

DHCP: Server msg received, fip=ANY, fport=0 on MOBILE interface

DHCPD: DHCPDISCOVER received from client 016c.c26b.293b.89 on interface MOBILE.

DHCPD: send ping pkt to 10.10.15.205

DHCPD: ping got no response for ip: 10.10.15.205

DHCPD: Add binding 10.10.15.205 to radix tree

DHCPD: Binding successfully added to hash table

DHCPD: Sending DHCPOFFER to client 016c.c26b.293b.89 (10.10.15.205).

DHCPD: client requests option 3.

DHCPD: copy option 3 (length = 4) to outgoing message.

DHCPD: client requests option 6.

DHCPD: copy option 6 (length = 8) to outgoing message.

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

DHCPD: creating ARP entry (10.10.15.205, 6cc2.6b29.3b89).

DHCPD: unicasting BOOTREPLY to client 6cc2.6b29.3b89 (10.10.15.205).

DHCPD: Binding successfully deactivated

dhcpd_destroy_binding() removing NP rule for client 10.10.15.205

DHCPD: free ddns info and binding

DHCP: Server msg received, fip=ANY, fport=0 on MOBILE interface

DHCPD: DHCPREQUEST received from client 016c.c26b.293b.89.

DHCPD: Extracting client address from the message

DHCPD: State = DHCPS_REBOOTING

DHCPD: State = DHCPS_REQUESTING

DHCPD: Client 016c.c26b.293b.89 specified it's address 10.10.15.205

DHCPD: Client is on the correct network

DHCPD: requested address 10.10.15.205 not found

DHCPD: Sending DHCPNAK to client 016c.c26b.293b.89.

DHCPD: broadcasting BOOTREPLY to client 6cc2.6b29.3b89.

2. Client without problem:

DHCP: Server msg received, fip=ANY, fport=0 on MOBILE interface

DHCPD: DHCPDISCOVER received from client 01bc.cfcc.736c.0e on interface MOBILE.

DHCPD: send ping pkt to 10.10.15.156

DHCPD: ping got no response for ip: 10.10.15.156

DHCPD: Add binding 10.10.15.156 to radix tree

DHCPD: Binding successfully added to hash table

DHCPD: Sending DHCPOFFER to client 01bc.cfcc.736c.0e (10.10.15.156).

DHCPD: client requests option 3.

DHCPD: copy option 3 (length = 4) to outgoing message.

DHCPD: client requests option 6.

DHCPD: copy option 6 (length = 8) to outgoing message.

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

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

DHCPD: unicasting BOOTREPLY to client bccf.cc73.6c0e (10.10.15.156).

DHCP: Server msg received, fip=ANY, fport=0 on MOBILE interface

DHCPD: DHCPREQUEST received from client 01bc.cfcc.736c.0e.

DHCPD: Extracting client address from the message

DHCPD: State = DHCPS_REBOOTING

DHCPD: State = DHCPS_REQUESTING

DHCPD: Client 01bc.cfcc.736c.0e specified it's address 10.10.15.156

DHCPD: Client is on the correct network

DHCPD: Client accepted our offer

DHCPD: Client and server agree on address 10.10.15.156

DHCPD: Renewing client 01bc.cfcc.736c.0e lease

DHCPD: Client lease can be renewed

DHCPD: Sending DHCPACK to client 01bc.cfcc.736c.0e (10.10.15.156).

DHCPD: Including FQDN option name 'Windows-Phone.MOBILE.ro' rcode1=0, rcode2=0 flags=0x0

DHCPD: client requests option 3.

DHCPD: copy option 3 (length = 4) to outgoing message.

DHCPD: client requests option 6.

DHCPD: copy option 6 (length = 8) to outgoing message.

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

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

DHCPD: unicasting BOOTREPLY to client bccf.cc73.6c0e (10.10.15.156).

As far as i can tell, DHCP leases for iOS devices are immidiately destroyed upon sending the DHCPOFFER packet. No idea why.

Antonio Simoes · ‎09-04-2013

Hi,

If you notice your Aplle device don´t accept the offer. Or the offer don´t reach to the client(Not to probably).

These are the messages that show that:

DHCPD: Client accepted our offer

DHCPD: Client and server agree on address 10.10.15.156

Try to unupdate one off your IOS deviece and try to put it work, it maybe was a Apple kill update.

You must contact Apple support man and see what they tell you.

Regards,

-AS

D-N · ‎09-04-2013

That's not correct.

Look above at output #1 (non-working Apple iPhone):

(snip)

DHCPD: unicasting BOOTREPLY to client 6cc2.6b29.3b89 (10.10.15.205).

DHCPD: Binding successfully deactivated

dhcpd_destroy_binding() removing NP rule for client 10.10.15.205

DHCPD: free ddns info and binding

(snip)

The bold lines immediately follow the ASA DHCPD's DHCPOFFER message. Why - I have no clue.

For output #2 (windows phone, no issues), those lines are not there for some reason.