Wireless 8.31 Bridging at AP unexpectedly

[John Kaftan]

Hello:

We have upgraded to 8.31 and are now managing our policy from PM. We are
having issues with some APs bridging some clients at the AP. I assume that
is what is happening because clients are getting on the same network that
the APs are on. This should not be the case because all of my VNS
topologies are bridging at the controller. It is pretty darn freaky since
that setting is set a the WLAN Service\Role level.

Has anyone else seen this issue? I'm freaking.

This causes big problems as security is bypassed as well as the wireless
clients are eating up all of the IPs on the LAN network and my wired
clients cannot connect.

[d***@fhsu.edu]

I was seeing this on 08.31 as well. Even with ***@HWC topology, clients
would sometimes end up on the AP's vlan even when assigned the correct
role. Usually cleared up with a disassociate/reassociate. Does that
sound like what you're seeing?

I upgraded to 08.32.01.0035 this morning and - so far - haven't seen any
clients assigned an IP from the AP DHCP pool, though haven't had chance
for more than a couple casual glances...

Derek Johnson | Data Communications Coordinator
FORT HAYS STATE UNIVERSITY
415 Lyman Dr. TH 101, Hays, KS 67601
(785) 628 - 5688 | ***@fhsu.edu





From: John Kaftan <***@utica.edu>
To: "Enterasys Customer Mailing List" <***@listserv.unc.edu>
Date: 11/12/2013 02:35 PM
Subject: [enterasys] Wireless 8.31 Bridging at AP unexpectedly



Hello:

We have upgraded to 8.31 and are now managing our policy from PM. We are
having issues with some APs bridging some clients at the AP. I assume
that is what is happening because clients are getting on the same network
that the APs are on. This should not be the case because all of my VNS
topologies are bridging at the controller. It is pretty darn freaky since
that setting is set a the WLAN Service\Role level.

Has anyone else seen this issue? I'm freaking.

This causes big problems as security is bypassed as well as the wireless
clients are eating up all of the IPs on the LAN network and my wired
clients cannot connect.
--
John Kaftan
IT Infrastructure Manager
Utica College

--To unsubscribe from enterasys, send email to ***@unc.edu with the
body: unsubscribe enterasys ***@fhsu.edu

---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org

[Yang, Charles]

Derek,
We have encountered the similar issue while we are using ***@HWC and just like you said that sometime the client would end up ***@AP.
After digging around, I think we have resolve the issue awhile back. Please note that this is awhile back, and it is not documented by GTAC so, please give it a try.

In the VNS configuration, by default, there are some WLAN services which default Topology is left as "blank" (eg. As "-")" according to the GTAC, they said that the default behavior of HWC will just forward to the default physical port out. However, we found that it is not 100% true. The HWC sometime, during the authentication state; HWC will get confused. (lack of better terms) In that situation, the user MAC address supposedly get dump on the HWC port, but it end up bleeding out on the switch port AP plugs into (another lack of better terms).

So, after consulting with GTAC, without a better solution, we just assign every Default Topology with a specific VLAN topology. (we are using multiple WLAN Services). The problem is no longer reoccurring.
We have also tested that to encrypt the channel between HWC and AP, did not resolve the bleeding out AP issue. ( ***@HWC just encapsulate, not encrypt)

Once again, this is purely speculative on our part of HWC behavior. Somehow we got lucky and resolved the issue. We configured the HWC on every segment of VNS config to tell the default topology to linked to a specific VLAN and stay away from using physical port unless the VNS is designed to do so. We don't have any problem since.

Hope these tips can help you.

Charles Yang
Sr. Network Security Architect
VTSP, ESC-Policy, ESC-NAC,

C: [phone]
O: [phone]
Jacobs Technology Inc.
Advance Consulting Group





From: ***@fhsu.edu [mailto:***@fhsu.edu]
Sent: Tuesday, November 12, 2013 3:46 PM
To: Enterasys Customer Mailing List
Subject: Re: [enterasys] Wireless 8.31 Bridging at AP unexpectedly

I was seeing this on 08.31 as well. Even with ***@HWC topology, clients would sometimes end up on the AP's vlan even when assigned the correct role. Usually cleared up with a disassociate/reassociate. Does that sound like what you're seeing?

I upgraded to 08.32.01.0035 this morning and - so far - haven't seen any clients assigned an IP from the AP DHCP pool, though haven't had chance for more than a couple casual glances...

Derek Johnson | Data Communications Coordinator
FORT HAYS STATE UNIVERSITY
415 Lyman Dr. TH 101, Hays, KS 67601
(785) 628 - 5688 | ***@fhsu.edu<mailto:***@fhsu.edu>





From: John Kaftan <***@utica.edu<mailto:***@utica.edu>>
To: "Enterasys Customer Mailing List" <***@listserv.unc.edu<mailto:***@listserv.unc.edu>>
Date: 11/12/2013 02:35 PM
Subject: [enterasys] Wireless 8.31 Bridging at AP unexpectedly
________________________________



Hello:

We have upgraded to 8.31 and are now managing our policy from PM. We are having issues with some APs bridging some clients at the AP. I assume that is what is happening because clients are getting on the same network that the APs are on. This should not be the case because all of my VNS topologies are bridging at the controller. It is pretty darn freaky since that setting is set a the WLAN Service\Role level.

Has anyone else seen this issue? I'm freaking.

This causes big problems as security is bypassed as well as the wireless clients are eating up all of the IPs on the LAN network and my wired clients cannot connect.




--
John Kaftan
IT Infrastructure Manager
Utica College

* --To unsubscribe from enterasys, send email to ***@unc.edu<mailto:***@unc.edu> with the body: unsubscribe enterasys ***@fhsu.edu<mailto:***@fhsu.edu>

* --To unsubscribe from enterasys, send email to ***@unc.edu<mailto:***@unc.edu> with the body: unsubscribe enterasys ***@massport.com<mailto:***@massport.com>

---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org

[John Kaftan]

Looks to be directly related to 2620s. Most of the clients I was seeing
were on 2620s. I shut them down and the issue went away. Got Enterasys on
the line and we tweaked the default Topology and default action for failed
Role assignment.

Looked on the log and it was full of these messages.

Config Manager has failed to process a request. Config Manager is still
running, and system functionality is not impaired. Error Details: AP
[0409920201202390] doesn't support role Non-Auth.

That AP is a 2620.

Post by d***@fhsu.edu
would sometimes end up on the AP's vlan even when assigned the correct
role. Usually cleared up with a disassociate/reassociate. Does that sound
like what you're seeing?
I upgraded to 08.32.01.0035 this morning and - so far - haven't seen any
clients assigned an IP from the AP DHCP pool, though haven't had chance for
more than a couple casual glances...
Derek Johnson | Data Communications Coordinator
FORT HAYS STATE UNIVERSITY
415 Lyman Dr. TH 101, Hays, KS 67601
Date: 11/12/2013 02:35 PM
Subject: [enterasys] Wireless 8.31 Bridging at AP unexpectedly
------------------------------
We have upgraded to 8.31 and are now managing our policy from PM. We are
having issues with some APs bridging some clients at the AP. I assume that
is what is happening because clients are getting on the same network that
the APs are on. This should not be the case because all of my VNS
topologies are bridging at the controller. It is pretty darn freaky since
that setting is set a the WLAN Service\Role level.
Has anyone else seen this issue? I'm freaking.
This causes big problems as security is bypassed as well as the wireless
clients are eating up all of the IPs on the LAN network and my wired
clients cannot connect.
--
John Kaftan
IT Infrastructure Manager
Utica College

[Mark Lamond]

Hi there,



This is my experience:



I have seen this on C4110's with 3610 AP's on various 8.x software levels.
It caused no end of head scratching!



If no default topology is set on your VNS, the default policy (under
"Global") is applied. As I understand it the default policy can come into
play for a number of reasons - failed Auth etc, and sometimes, very
occasionally for no obvious reason at all when a client connects.



By default the global policy is to bridge at AP untagged and the associated
filter rules allow all traffic. It's dangerous default behaviour in my
opinion! Deny would be safer because this leakage of traffic would have gone
un-noticed had we not been running DHCP in the AP VLAN. Be sure to change
the HWC and AP filter rules to deny all on all controllers as a safeguard,
if you do not want to use the default policy.



On a basic VNS, where no dynamic policy is occuring we are always sure to
assign the default topology on the WLAN service to be the same as that in
the associated policy. That way should something odd happen as the
controller processes the client's request to connect, clients will always
stay in the correct topology.



Also, if you are dynamically changing policy using NAC/RADIUS etc the
problem is more likely to occur. There appears to be a transition stage in
the process where your client has the default policy applied.



With an unrestricted default policy in place if the client happens to
perform a DHCP request during that time it may end up with an address from
the VLAN your AP resides in.



To add more confusion, by the time you look at the reporting screen it will
show the correct policy applied - yet the client has an invalid IP it has
obtained from the AP VLAN! And because the client has what it thinks is a
valid IP, when the policy finally does change the client does not request
another DHCP address and happily sits there, unable to communicate.



Very confusing - a wireshark capture taken from the AP radio and Ethernet
interfaces (great feature by the way) proved what was going on. This all
happens in a very short time window, but it is enough for a DHCP server to
answer back and reply to the DHCP request.



I'm glad Charles has described exactly the same behaviour and solution.



Mark.











_____

From: John Kaftan [mailto:***@utica.edu]
Sent: 12 November 2013 8:35 PM
To: Enterasys Customer Mailing List
Subject: [enterasys] Wireless 8.31 Bridging at AP unexpectedly



Hello:



We have upgraded to 8.31 and are now managing our policy from PM. We are
having issues with some APs bridging some clients at the AP. I assume that
is what is happening because clients are getting on the same network that
the APs are on. This should not be the case because all of my VNS
topologies are bridging at the controller. It is pretty darn freaky since
that setting is set a the WLAN Service\Role level.




Has anyone else seen this issue? I'm freaking.



This causes big problems as security is bypassed as well as the wireless
clients are eating up all of the IPs on the LAN network and my wired clients
cannot connect.
--
John Kaftan

IT Infrastructure Manager

Utica College



* --To unsubscribe from enterasys, send email to ***@unc.edu with
the body: unsubscribe enterasys ***@marklamond.co.uk


---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org