clients disconnect from guest wifi

[Alwin Dsouza]

clients disconnected from guest SSID,

guest trafiic is through mobility anchor and authorization is from ISE

i can see the tunnel data and control path is UP on anchor and foreign WLC.

Problem # authentication takes place.. after the authentication IP is changed to 169.  and the client is disconnected.. i have attached the logs..

" *apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Change state to DHCP_REQD (7) last state RUN (20) "

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Re-applying interface policy for client

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 WEBAUTH_REQD (8) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2641)
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 WEBAUTH_REQD (8) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2662)
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c apfApplyWlanPolicy: Apply WLAN Policy over PMIPv6 Client Mobility Type, Tunnel User - 0
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Inserting AAA Override struct for mobile
MAC: 84:89:ad:80:e5:9c, source 48

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Setting session timeout 65595 on mobile 84:89:ad:80:e5:9c
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Session Timeout is 65595 - starting session timer for the mobile
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c AAA override is enabled and interface doesnot exist use the VLAN id inthe nac payload -1 for 84:89:ad:80:e5:9c
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 WEBAUTH_REQD (8) Change state to WEBAUTH_NOL3SEC (14) last state WEBAUTH_REQD (8)

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c apfMsRunStateInc
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 WEBAUTH_NOL3SEC (14) Change state to RUN (20) last stateWEBAUTH_NOL3SEC (14)

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Stopping deletion of Mobile Station: (callerId: 74)
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Session Timeout is 65595 - starting session timer for the mobile
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Reached PLUMBFASTPATH: from line 6928
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Plumbing duplex mobility tunnel to apfMmPeerIp:10.210.23.165,remTunIp:10.210.23.163
as Export Anchor (VLAN 941)
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c Tunnel id 1 found for ip 10.210.23.163

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Replacing Fast Path rule
type = Airespace AP Client
on AP 00:00:00:00:00:00, slot 0, interface = 13, QOS = 3
IPv4 ACL ID = 255, IPv6 ACL ID
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0,TokenID = 15206, IntfId = 12 Local Bridging Vlan = 941, Local Bridging intf id = 12
*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Fast Path rule (contd...) AVC Ratelimit: AppID= 0 ,AppAction = 0, AppToken = 15206 AverageRate = 0, BurstRate = 0

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Fast Path rule (contd...) AVC Ratelimit: AppID= 0 ,AppAction = 0, AppToken = 15206 AverageRate = 0, BurstRate = 0

*ewmwebWebauth1: Dec 20 12:58:44.161: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Fast Path rule (contd...) AVC Ratelimit: AppID= 0 ,AppAction = 0, AppToken = 15206 AverageRate = 0, BurstRate = 0

*ewmwebWebauth1: Dec 20 12:58:44.162: 84:89:ad:80:e5:9c Accounting NAI-Realm: nc@gmail.com, from Mscb username : nc@gmail.com
*ewmwebWebauth1: Dec 20 12:58:44.162: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255)
*ewmwebWebauth1: Dec 20 12:58:44.162: 84:89:ad:80:e5:9c Sending client update msg type 0 to foreign peer 10.210.23.165.

*ewmwebWebauth1: Dec 20 12:58:44.162: AAA Override QoS payload Build, Total Payload length 41

*ewmwebWebauth1: Dec 20 12:58:44.162: 84:89:ad:80:e5:9c client mac = 84:89:AD:80:E5:9C AAA Override QoS Payload Build.

*pemReceiveTask: Dec 20 12:58:44.164: 84:89:ad:80:e5:9c Set bi-dir guest tunnel for 84:89:ad:80:e5:9c as in Export Anchor role
*pemReceiveTask: Dec 20 12:58:44.164: 84:89:ad:80:e5:9c 172.22.1.167 Added NPU entry of type 1, dtlFlags 0x4
*pemReceiveTask: Dec 20 12:58:44.164: 84:89:ad:80:e5:9c Sending a gratuitous ARP for 172.22.1.167, VLAN Id 941
*mcListen: Dec 20 12:58:44.165: 84:89:ad:80:e5:9c Client Update Ack Done sent to IP: 172.22.0.5

*mcListen: Dec 20 12:58:44.165: 84:89:ad:80:e5:9c Forwarding Client Update message to IP addr 10.210.23.163

*mmMaListen: Dec 20 12:58:44.171: mmProcessInMsg:Rcvd ACK msg for client update msg from foreign wlc

*mcListen: Dec 20 12:58:45.121: 84:89:ad:80:e5:9c Client Delete Ack Done sent to IP: 10.210.23.163

*mcListen: Dec 20 12:58:45.121: 84:89:ad:80:e5:9c Forwarding Client Delete message to 1 IP addr 172.22.0.5

*mmMaListen: Dec 20 12:58:45.121: 84:89:ad:80:e5:9c mm_exec_mobAgent_fsm:600 currState:Anchor, event:MM_MAFSM_EV_REMOTE_DELETE_CLIENT, caller mmProcessInMsg:1288
*apfReceiveTask: Dec 20 12:58:45.121: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) mobility role update request from Export Anchorto Handoff
Peer = 10.210.23.165, Old Anchor = 172.22.0.5, New Anchor = 0.0.0.0
*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Skipping TMP rule add
*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c apfMsRunStateDec
*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 RUN (20) Change state to DHCP_REQD (7) last state RUN (20)

*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 DHCP_REQD (7) Change state to DHCP_REQD (7) last state DHCP_REQD (7)

*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 DHCP_REQD (7) Plumbing duplex mobility tunnel to apfMmPeerIp:0.0.0.0,remTunIp:0.0.0.0
as Export Anchor (VLAN 941)
*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 DHCP_REQD (7) Replacing Fast Path rule
type = Airespace AP - Learn IP address
on AP 00:00:00:00:00:00, slot 0, interface = 13, QOS = 3
IPv4 ACL ID =
*apfReceiveTask: Dec 20 12:58:45.122: 84:89:ad:80:e5:9c 172.22.1.167 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP= 0, TokenID = 15206, IntfId = 12 Local Bridging Vlan = 941, Local Bridging intf id = 12

[Leo Laohoo]

This is not a wireless issue.
If the clients' IP address changes from 172.22.1.X to a 169.254.X.X then I'd be looking at the DHCP server first.
Logs show a lot of "DHCP_REQD".

[Alwin Dsouza]

Hello Leo,

Initially when they connect the ip is assigned from the internal dhcp server created on anchor, my case it was 172.22.1.167, the ip changed to 169 once the login is done on the guest portal, but the login is success.. also i checked authentication on ISE.. shows success..

[Leo Laohoo · Accepted solution]

If wireless clients are getting 169.254.X.X address then ISE has nothing to do with it.  Check the DHCP server based on the anchor controller.  Maybe the dynamic interface of the anchor controller is pointing to the wrong DHCP server?

[Alwin Dsouza]

wireless client are initially getting ip from 172.22.1.X pool.. and the ip is changed after successful login.. 

as suggested by you i will check the dhcp settings..on the dynamic interface..

[Scott Fella · Accepted solution]

The auth when anchoring happens on the anchor controller along with dhcp. If the scope is getting obtained from the foreign then that’s your issue. So the ancho has to send the auth back to ISE and dhcp is on the local subnet where the anchor controller sits.

[Freerk Terpstra · Accepted solution]

Is changing the end-points IPv4 address after authentication your intention? If not, check for interface override configuration as authentication result within ISE. My recommendation is don't do this with webauth since the end-point is not aware that the VLAN changed and might not even restart its DHCP process and simply disassociate from the network.

In case you mean that the end-points are getting another IPv4 address in same the VLAN, I recommend to verify the DHCP relay and server configuration on the anchor side. Things to check are scope space and lease duration (should be in syn with the session-time on the controllers).

Please rate useful posts... :-)

[Alwin Dsouza]

Hello Friends,

thanks all for your post, i was on holidays hence could not test.. now i removed the allow AAA override and seems to be working fine..