Security

Please let me know if I posted in the wrong board.

Here is the scenario:

User connects to RAP, receives an IP from the controller hosted DHCP server. Example: user IP: 192.168.1.100

Processes external captive portal

Is now on a post-authentication role.

Client appears in the user table with the controller provided address 192.168.1.100 and another IP address.

Starting with a 25.x.y.z IP address.

Deleting the 25.x.y.z IP entry, the client losses connection and in turn would not be able to reconnect.

We opened a TAC case for this and they suggested the following:

1.    Since the users are getting an IP address from the controllers DHCP server, we can enable the ‘enforce DHCP’ option under the respective AAA profile.
a.    When this option is enabled on the controller, the users will not be allowed to associate to an access point, until and unless they obtain an IP address from the DHCP. This would eliminate the static IP address entries from being shown on the user-table.
b.    However make sure when you delete the user from the user-table, that particular client will not be able to send traffic until it renews the IP address from the DHCP server.
2.    The ‘Prohibit ARP spoofing’ option present on the firewall could also be enabled on the controller, this would detect possible ARP spoofing attacks. However this change is global and would affect all the users on the controller, unlike the previous option.

A few things that I would like to know:

1. Why is the user getting 2 IP addresses where the 2nd IP is not from any subnet that we know of.

2. Are the settings above enough? What impact does it have?

Since we host multiple customers on this 1 controller, some settings ar globally applie like 'Prohibit ARP Spoofing'.

Thanks,

Is the IP the user is getting a wired IP assigned  ?

Is it from a valid IP space ?

Thanks

Not at all a wired user.

Here is what we see 1 min after authentication:

192.168.6.234   14:7d:c5:68:xx:yy  TIM-DD877B0D-00E5-46A2-8413-BD5251D7EED3  split_user_macs            00:00:03    Web             00:24:6c:c6:99:99  Associated(Remote)  MacsWIFI/00:24:6c:e8:99:99/g     3ap_macs             split tunnel  Android
10.119.135.195  14:7d:c5:68:xx:yy  TIM-DD877B0D-00E5-46A2-8413-BD5251D7EED3  split_user_macs            00:00:04    Web             00:24:6c:c6:99:99      Associated(Remote)  MacsWIFI/00:24:6c:e8:99:99/g            3ap_macs             split tunnel  Android

 Removing the 10.119.135.195 using aaa user delete ip-addr, causes the user to go offline and cannot re-connect.

Until we remove both entries, the user will no longer be able to connect.

(uat-wlc-1.tdl.c6.dv) #show user-table | in 2b:17
25.48.44.240  00:23:76:ce:fg:gh  ARU-4811712B-A0DE-4A01-A5CC-A6DFB000A815@tim tdl_memberfree_user  00:00:17    Web             d8:c7:c8:c6:74:2b  Associated(Remote)  UAT Tim /d8:c7:c8:e7:aa:aa/g-HT  3ap_tdl_ca_uat  split tunnel  Android
10.53.0.208   00:23:76:ce:fg:gh  ARU-4811712B-A0DE-4A01-A5CC-A6DFB000A815@timhortons  tdl_memberfree_user  00:00:17    Web             d8:c7:c8:c6:AA:AA  Associated(Remote)  UAT Tim /d8:c7:c8:e7:aa:aa/g-HT  3ap_tdl_ca_uat  split tunnel  Android

I am getting it with my android as well. Valid IP 10.53.0.208, incorrect 25.48.44.240....

What AOS code do you have on that controller?

Is 25.x.x.x the local IP Space or the ISP ?

You might have to implement "enforce-dhcp" or changed the valid user table .

We were thinking of enforce-dhcp option but it involves a few options that we are not 100% sure about.

the 25.x.y.z is not the local IP space for ISP

That's a really weird behavior.

I think for security purposes you should the define what IP Spaces are going to be allowed and you can do this by creating a netdestination with the valid IP Spaces and then applying it to the valid user table .

Interesting, this is something I would need to test but it still doesn't answer why that 2nd IP is there.

What code are you running ?

Are you connecting through a RAP ?

Can you do a show datapath session table on one of the 25.x.x.x ? and also do a trace ?

Code version 6.1.4.0 (special version released only by SE's) - Support for RAP-3's, bandwidth contracts, External Captive Portal Fixes, etc.

Running RAPs

show datapath session | include 25.64.247.112

Returns nothing, probably because the user has not timed out yet and is no longer there.

Interesting.

I am running the same code for my RAP3's and I am also using one of the VAP's in split tunnel mode.

But I'm not experiencing that issue.

How did you configure your split tunnel ACLs/USER-ROLE ?

This is the access-list that I was talking about :

ip access-list session validuser
any any svc-sec-papi permit
network 169.254.0.0 255.255.0.0 any any deny

network 25.x.x.x 255.x.x.x any any deny
any any any permit
ipv6 any any any permit

But  as you mention test it first before deploying it.

not using the validuser acl, this is what I got.

Look for your android or laptop IP address and then just add that IP address and see if you can still get a connection after you deny that IP address or if you have a test environment tried there.

interesting, i always experience the same IP wise when i connect my android phone, it shows two IP addresses, never tried to remove one. will try this when i have some time.