James Andrewartha
2013-11-27 07:26:13 UTC
Hi,
I was reading the 8.32.02.0006 release notes and noticed the following
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org
I was reading the 8.32.02.0006 release notes and noticed the following
wns0007074-Info
A partially specified policy is one that has No change selected for
filters, default topology or default qos. When a
partially specified policy is assigned to a station the no change
settings are replaced by the elements from
another policy applied to the station. When a station successfully
authenticates and is assigned a partially
specified policy, the No change elements of the policy are replaced
with the corresponding elements of the
WLAN Services default authenticated policy.
Consider the following example. Suppose a VNS is defined that uses
policy P1 for its default non-authenticated
policy and policy P2 for its default authenticated policy. Policy P1
assigns the station to topology T1 and policy P2
assigns the station to topology T2. Suppose there is a policy P3, that
has "no change" set for its topology
A client on the VNS will be assigned to P1 with topology T1 when he
first associates to the VNS. Now suppose
the station is assigned P3 by the RADIUS server when the station
authenticates.
Even though the station is on T1
and P3 has no change set for the topology, the station will be
assigned to T2. When the client is authenticated,
internally on the controller, the client is first assigned to P2 then
P3 is applied.
A similar scenario
exists when the hybrid mode policy feature is set to use tunnel
-
private
-
group
-
id to assign both
policy and topology but for some reason the VLAN
-
id
-
to
-
Policy mapping table does not contain a mapping for the
returned tunnel private group id. In this case a
station that successfully authenticates would be assigned the
filters and default QoS of the WLAN Services default authenticated
policy and the topology with the VLANID
contained in the Tunnel
-
Private
-
Group
-
ID of the ACCESS
-
ACCEPT response.
If this is no
t the desired behavior, then
1. Avoid using partially specified policies.
2. When the controller is configured to map the VLAN ID in the Tunnel
-
Private
-
Group
-
ID response to a policy
using the mapping table, ensure that there is a policy mapping for each
VLAN ID that can be returned to the
controller by the RADIUS server.
Hi there,
I have seen this on C4110s with 3610 APs 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. Its 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 clients 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.
Im glad Charles has described exactly the same behaviour and solution.
Mark.
------------------------------------------------------------------------
*Sent:* 12 November 2013 8:35 PM
*To:* Enterasys Customer Mailing List
*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
--A partially specified policy is one that has No change selected for
filters, default topology or default qos. When a
partially specified policy is assigned to a station the no change
settings are replaced by the elements from
another policy applied to the station. When a station successfully
authenticates and is assigned a partially
specified policy, the No change elements of the policy are replaced
with the corresponding elements of the
WLAN Services default authenticated policy.
Consider the following example. Suppose a VNS is defined that uses
policy P1 for its default non-authenticated
policy and policy P2 for its default authenticated policy. Policy P1
assigns the station to topology T1 and policy P2
assigns the station to topology T2. Suppose there is a policy P3, that
has "no change" set for its topology
A client on the VNS will be assigned to P1 with topology T1 when he
first associates to the VNS. Now suppose
the station is assigned P3 by the RADIUS server when the station
authenticates.
Even though the station is on T1
and P3 has no change set for the topology, the station will be
assigned to T2. When the client is authenticated,
internally on the controller, the client is first assigned to P2 then
P3 is applied.
A similar scenario
exists when the hybrid mode policy feature is set to use tunnel
-
private
-
group
-
id to assign both
policy and topology but for some reason the VLAN
-
id
-
to
-
Policy mapping table does not contain a mapping for the
returned tunnel private group id. In this case a
station that successfully authenticates would be assigned the
filters and default QoS of the WLAN Services default authenticated
policy and the topology with the VLANID
contained in the Tunnel
-
Private
-
Group
-
ID of the ACCESS
-
ACCEPT response.
If this is no
t the desired behavior, then
1. Avoid using partially specified policies.
2. When the controller is configured to map the VLAN ID in the Tunnel
-
Private
-
Group
-
ID response to a policy
using the mapping table, ensure that there is a policy mapping for each
VLAN ID that can be returned to the
controller by the RADIUS server.
Hi there,
I have seen this on C4110s with 3610 APs 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. Its 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 clients 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.
Im glad Charles has described exactly the same behaviour and solution.
Mark.
------------------------------------------------------------------------
*Sent:* 12 November 2013 8:35 PM
*To:* Enterasys Customer Mailing List
*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
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org