Wireless Access

Hello,

We are playing with configuring OWE enhanced open on our test system for a Guest captive portal SSID. The portal for this is provided by ClearPass.

We have enhanced open configured in transition mode and I'm doing some testing.

On my Pixel 4a I get to the Guest captive portal and choose an option to authenticate, but auth fails. Looking in Access Tracker on ClearPass I can see that the requests aren't matching a service because the SSID in the RADIUS packet is "_owetm_UniOfCam-Guest-T_2a5f79e2". I guess this is the 'hidden' SSID that clients are directed to (not sure if that is clients that _do_ support OWE or clients that don't, but anyway). 

My question is is this right, or is it a bug? Should ClearPass see that request as being the hidden SSID name (in which case do we have to create a new Service on ClearPass to handle these requests) or should it see the 'normal' essid and the requests match to the existing service?

Guy

Hi Guy.

This is expected behavior. You need to change your matching condition to CONTAINS instead of EQUAL.

Best, Gorazd

Hello,

We are playing with configuring OWE enhanced open on our test system for a Guest captive portal SSID. The portal for this is provided by ClearPass.

We have enhanced open configured in transition mode and I'm doing some testing.

On my Pixel 4a I get to the Guest captive portal and choose an option to authenticate, but auth fails. Looking in Access Tracker on ClearPass I can see that the requests aren't matching a service because the SSID in the RADIUS packet is "_owetm_UniOfCam-Guest-T_2a5f79e2". I guess this is the 'hidden' SSID that clients are directed to (not sure if that is clients that _do_ support OWE or clients that don't, but anyway). 

My question is is this right, or is it a bug? Should ClearPass see that request as being the hidden SSID name (in which case do we have to create a new Service on ClearPass to handle these requests) or should it see the 'normal' essid and the requests match to the existing service?

Guy

Great thank you Gorazd, I just tested that and it works. Out of interest do you know which clients end up using that hidden SSID? Is that for clients that don't support OWE?

Hi Guy.

This is expected behavior. You need to change your matching condition to CONTAINS instead of EQUAL.

Best, Gorazd

Hello,

We are playing with configuring OWE enhanced open on our test system for a Guest captive portal SSID. The portal for this is provided by ClearPass.

We have enhanced open configured in transition mode and I'm doing some testing.

On my Pixel 4a I get to the Guest captive portal and choose an option to authenticate, but auth fails. Looking in Access Tracker on ClearPass I can see that the requests aren't matching a service because the SSID in the RADIUS packet is "_owetm_UniOfCam-Guest-T_2a5f79e2". I guess this is the 'hidden' SSID that clients are directed to (not sure if that is clients that _do_ support OWE or clients that don't, but anyway). 

My question is is this right, or is it a bug? Should ClearPass see that request as being the hidden SSID name (in which case do we have to create a new Service on ClearPass to handle these requests) or should it see the 'normal' essid and the requests match to the existing service?

Guy

So here is the background for OWE transition mode. Check the following SSID demo-owe, it creates two actual BSSIDs:

AP303H-1a:68# show ap bss-tableAruba AP BSS Table------------------                                                                                                                                                                                                                    bss                ess                        port  ip              band/ht-mode/bandwidth  ch/EIRP/max-EIRP  type  cur-cl  ap name       in-t(s)  tot-t          flags---                ---                        ----  --              ----------------------  ----------------  ----  ------  -------       -------  -----          -----24:f2:7f:d1:8f:f1  demo-owe                   ?/?   192.168.33.160  5GHz/VHT/80MHz          56E/18.0/23.0     ap    0       AP303H-1a:68  0        23s            o24:f2:7f:d1:8f:f2  _owetm_demo-owe1850912771  ?/?   192.168.33.160  5GHz/VHT/80MHz          56E/18.0/23.0     ap    0       AP303H-1a:68  0        23s            OWFlags:       o = Enhanced-open transition mode open BSS; O = Enhanced-open BSS with transition mode;

The 'normal' name is the open network, such that legacy clients can connect with the correct name.

If you run a wireless capture, you will see that the _owetm_demo (etc) it hidden, the open demo-owe contains in the beacon information for the actual OWE network:

You can see the BSSID (ending on :f2) and the SSID of the hidden OWE SSID.

If I connect two clients, one OWE capable, the other 'legacy', you can see:

AP303H-1a:68# show ap associationThe phy column shows client's operational capabilities for current associationFlags: H: Hotspot(802.11u) client, K: 802.11K client, M: Mu beam formee, R: 802.11R client, W: WMM client, w: 802.11w client, V: 802.11v BSS trans capable, P: Punctured preamble, U: HE UL Mu-mimo, O: OWE client, S: SAE client, E:Enterprise client, m: Agile Multiband client, C: Cellular Data Capable - network available, c: Cellular Data Capable - network unavailable, T: Individual TWT client, t: Broadcast TWT clientPHY Details: HT   : High throughput;      20: 20MHz;  40: 40MHz; t: turbo-rates (256-QAM)             VHT  : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz             HE   : High Efficiency;       80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz             <n>ss: <n> spatial streamsAssociation Table-----------------Name          bssid              mac                auth  assoc  aid  l-int  essid                      vlan-id  phy                 assoc. time  num assoc  Flags   DataReady       UAC----          -----              ---                ----  -----  ---  -----  -----                      -------  ---                 -----------  ---------  -----   ---------       ---AP303H-1a:68  24:f2:7f:d1:8f:f2  mo:de:rn:cl:f7:77  y     y      1    10     _owetm_demo-owe1850912771  1        5GHz-VHT-80sgi-2ss  2s           1          WVwMOT  Yes (Implicit)  0.0.0.0AP303H-1a:68  24:f2:7f:d1:8f:f1  le:ga:cy:cl:99:e0  y     y      1    1      demo-owe                   1        5GHz-HT-40sgi-1ss   13s          1          WV      Yes (Implicit)  0.0.0.0Num Clients:2

To summarize: two separate SSIDs are broadcasted, note that both take airtime and OWE transition mode takes double the airtime for beacons from just open or just OWE. Legacy clients will just connect to the open network. OWE capable clients will learn from the open SSID beacon where to connect to the actual OWE network.

Legacy clients connect to the the configured SSID, OWE clients will connect to the hidden _owetm_SSID#########. For authentication, in the RADIUS packet the actual SSID is passed, so for OWE capable clients that will be the long _owetm_ version, and for that reason you could use 'Aruba-ESSID CONTAINS demo-owe' instead of 'Aruba-ESSID EQUALS demo-owe' in such a case.

Great thank you Gorazd, I just tested that and it works. Out of interest do you know which clients end up using that hidden SSID? Is that for clients that don't support OWE?

Hi Guy.

This is expected behavior. You need to change your matching condition to CONTAINS instead of EQUAL.

Best, Gorazd

Hello,

We are playing with configuring OWE enhanced open on our test system for a Guest captive portal SSID. The portal for this is provided by ClearPass.

We have enhanced open configured in transition mode and I'm doing some testing.

On my Pixel 4a I get to the Guest captive portal and choose an option to authenticate, but auth fails. Looking in Access Tracker on ClearPass I can see that the requests aren't matching a service because the SSID in the RADIUS packet is "_owetm_UniOfCam-Guest-T_2a5f79e2". I guess this is the 'hidden' SSID that clients are directed to (not sure if that is clients that _do_ support OWE or clients that don't, but anyway). 

My question is is this right, or is it a bug? Should ClearPass see that request as being the hidden SSID name (in which case do we have to create a new Service on ClearPass to handle these requests) or should it see the 'normal' essid and the requests match to the existing service?

Guy

Thanks Herman, this is a really useful explanation.

Is the hidden SSID just a standard hidden SSID, is there anything special about it in terms of client devices seeing it? My reason for asking is that some client devices detect and show hidden SSIDs, so if that were the case I guess we may get some users seeing it on their devices and questioning what it is. Or is it hidden in some special way that means devices will not show it in the wireless networks list? 

So here is the background for OWE transition mode. Check the following SSID demo-owe, it creates two actual BSSIDs:

AP303H-1a:68# show ap bss-tableAruba AP BSS Table------------------                                                                                                                                                                                                                    bss                ess                        port  ip              band/ht-mode/bandwidth  ch/EIRP/max-EIRP  type  cur-cl  ap name       in-t(s)  tot-t          flags---                ---                        ----  --              ----------------------  ----------------  ----  ------  -------       -------  -----          -----24:f2:7f:d1:8f:f1  demo-owe                   ?/?   192.168.33.160  5GHz/VHT/80MHz          56E/18.0/23.0     ap    0       AP303H-1a:68  0        23s            o24:f2:7f:d1:8f:f2  _owetm_demo-owe1850912771  ?/?   192.168.33.160  5GHz/VHT/80MHz          56E/18.0/23.0     ap    0       AP303H-1a:68  0        23s            OWFlags:       o = Enhanced-open transition mode open BSS; O = Enhanced-open BSS with transition mode;

The 'normal' name is the open network, such that legacy clients can connect with the correct name.

If you run a wireless capture, you will see that the _owetm_demo (etc) it hidden, the open demo-owe contains in the beacon information for the actual OWE network:

You can see the BSSID (ending on :f2) and the SSID of the hidden OWE SSID.

If I connect two clients, one OWE capable, the other 'legacy', you can see:

AP303H-1a:68# show ap associationThe phy column shows client's operational capabilities for current associationFlags: H: Hotspot(802.11u) client, K: 802.11K client, M: Mu beam formee, R: 802.11R client, W: WMM client, w: 802.11w client, V: 802.11v BSS trans capable, P: Punctured preamble, U: HE UL Mu-mimo, O: OWE client, S: SAE client, E:Enterprise client, m: Agile Multiband client, C: Cellular Data Capable - network available, c: Cellular Data Capable - network unavailable, T: Individual TWT client, t: Broadcast TWT clientPHY Details: HT   : High throughput;      20: 20MHz;  40: 40MHz; t: turbo-rates (256-QAM)             VHT  : Very High throughput; 80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz             HE   : High Efficiency;       80: 80MHz; 160: 160MHz; 80p80: 80MHz + 80MHz             <n>ss: <n> spatial streamsAssociation Table-----------------Name          bssid              mac                auth  assoc  aid  l-int  essid                      vlan-id  phy                 assoc. time  num assoc  Flags   DataReady       UAC----          -----              ---                ----  -----  ---  -----  -----                      -------  ---                 -----------  ---------  -----   ---------       ---AP303H-1a:68  24:f2:7f:d1:8f:f2  mo:de:rn:cl:f7:77  y     y      1    10     _owetm_demo-owe1850912771  1        5GHz-VHT-80sgi-2ss  2s           1          WVwMOT  Yes (Implicit)  0.0.0.0AP303H-1a:68  24:f2:7f:d1:8f:f1  le:ga:cy:cl:99:e0  y     y      1    1      demo-owe                   1        5GHz-HT-40sgi-1ss   13s          1          WV      Yes (Implicit)  0.0.0.0Num Clients:2

To summarize: two separate SSIDs are broadcasted, note that both take airtime and OWE transition mode takes double the airtime for beacons from just open or just OWE. Legacy clients will just connect to the open network. OWE capable clients will learn from the open SSID beacon where to connect to the actual OWE network.

Legacy clients connect to the the configured SSID, OWE clients will connect to the hidden _owetm_SSID#########. For authentication, in the RADIUS packet the actual SSID is passed, so for OWE capable clients that will be the long _owetm_ version, and for that reason you could use 'Aruba-ESSID CONTAINS demo-owe' instead of 'Aruba-ESSID EQUALS demo-owe' in such a case.

Great thank you Gorazd, I just tested that and it works. Out of interest do you know which clients end up using that hidden SSID? Is that for clients that don't support OWE?

Hi Guy.

This is expected behavior. You need to change your matching condition to CONTAINS instead of EQUAL.

Best, Gorazd

Hello,

We are playing with configuring OWE enhanced open on our test system for a Guest captive portal SSID. The portal for this is provided by ClearPass.

We have enhanced open configured in transition mode and I'm doing some testing.

On my Pixel 4a I get to the Guest captive portal and choose an option to authenticate, but auth fails. Looking in Access Tracker on ClearPass I can see that the requests aren't matching a service because the SSID in the RADIUS packet is "_owetm_UniOfCam-Guest-T_2a5f79e2". I guess this is the 'hidden' SSID that clients are directed to (not sure if that is clients that _do_ support OWE or clients that don't, but anyway). 

My question is is this right, or is it a bug? Should ClearPass see that request as being the hidden SSID name (in which case do we have to create a new Service on ClearPass to handle these requests) or should it see the 'normal' essid and the requests match to the existing service?

Guy