Security

Reply
Contributor I

strange IP addresses for Guest_Logon under captive portal

I'm noticing several devices that are in a logon role under my captive portal guest wireless network.  They are showing 192.168.10.x addresses but I only have 192.168.64.x/22 assigned to CP-DHCP.  These are not statically IP'ed devices, but seems like an iphone is connecting to my guest portal and acting as a hotspot, then issuing its own variance of DHCP for devices associating with the hotspot device.

 

Has anyone else witnessed this and is there a means of blocking this capability (hotspot in the middle)?  They're not getting on my guest because they don't have the passphrase and auth credentials, but my valid guest clients are also hitting the hotspot (if this is even the case).  I don't want to do preferred AP setup on guests so they only connect to my aruba APs, but was wondering if anyone else has witnessed such an event and what actions you took to mitigate?

Re: strange IP addresses for Guest_Logon under captive portal

In the captive portal login role, you can create and add a policy to the top of the list to DENY udp 68 packets which are DHCP reply packets.  If you have a rogue DHCP server, this line will prevent IP addresses from being handed out.

 

The syntax would be

 

ip access-list session prevent-rogue-dhcp-server

  user any udp 68  deny

 

user-role cp-role

 captive-portal "cp-profile"

 access-list session prevent-rogue-dhcp-server

 access-list session logon-control

 access-list session captiveportal

 

Seth R. Fiermonti
Consulting Systems Engineer - ACCX, ACDX, ACMX
Email: seth@hpe.com
-----
If you found my post helpful, please give kudos
New Contributor

Re: strange IP addresses for Guest_Logon under captive portal

We have been having the same issue; I am curious to know if you were able to remedy this using the DHCP rule listed in this page?

 

Thank you,

Joe

Contributor I

Re: strange IP addresses for Guest_Logon under captive portal

Our scenario ended up being a local controller "wired" port residing in our captive portal vlan. Said port was cfg'ed for trusted. Someone needed a dirty feed wired connection and used this port. The device was a standalone switch providing multiple dirty wired connections. Something running a dhcp service was plugged into the separate switch. We simply created an ACL blocking dhcp server (67-68) inbound to the controller wired port which remediated the issue for us.

DOH "I'Phoned" to You!
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: