PC's are forced in Captive Portal

[TechBu]

Hi,

We are trying to implement 802.1x on our campus but we’ve encountered a problem with captive portal (CP).
We don’t need a CP, therefore nothing is configured to point the PC’s to the CP, except the default values which can’t be removed.

Problem;
In some cases an authenticated PC looses its connection. By a expired timer or when the PC goes into (hybrid) sleep/hibernate, even without reason.
Those PC’s are supplicants and should pass the 802.1x authentication, but sometimes they don’t. So the policy states that they should go to another user network profile where they can access the internet, but not our intranet.
Instead, sometimes they go to the CP.

Actions we’ve took sofar;
-Most of the time a re-initialize solves the problem, but this is not doable when we migrate our full network
-All the switches have the latest IOS (6.6.4.177.R01)
-We played with the timers on the switch, PC (block-timers, etc.) and radius-server
-We’ve captured packets on the exact moment when a PC goes into the CP-state, but we don’t see any triggers that would cause a de-authentication or…

Here's the config we use;

aaa-config:

Code: Select all

aaa radius-server "NPS1" host 10.0.161.191 key xxx retransmit1 timeout 2 auth-port 1812 acct-port 1813
aaa radius-server "NPS2" host 10.0.161.193 key xxx retransmit1 timeout 2 auth-port 1812 acct-port 1813
aaa authentication default "local"
aaa authentication console "NPS1" "NPS2" "local"
aaa authentication telnet "NPS1" "NPS2" "local"
aaa authentication ftp "NPS1" "NPS2" "local"
aaa authentication http "NPS1" "NPS2" "local"
aaa authentication ssh "NPS1" "NPS2" "local"
aaa authentication 802.1x "NPS1" "NPS2"
aaa authentication mac "NPS1" "NPS2"
aaa user-network-profile name "CNET" vlan 100 hic disable
aaa user-network-profile name "PNET" vlan 29 hic disable

802.1X config:

Code: Select all

802.1x auth-server-down enable
802.1x auth-server-down re-authperiod 1500
802.1x auth-server-down policy user-network-profile CNET
802.1x 1/1 direction both port-control auto quiet-period 60 tx-period 30 supp-timeout 30 server-timeout 60 max-req 2 re-authperiod 3600  reauthentication
802.1x 1/1 captive-portal session-limit 12 retry-count 3
802.1x 1/1 supp-polling retry 2
802.1x 1/1 captive-portal inactivity-logout enable
802.1x 1/1 supplicant policy authentication pass block fail user-network-profile PNET block
802.1x 1/1 non-supplicant policy authentication pass block fail group-mobility user-network-profile PNET block
802.1x 1/1 captive-portal policy authentication pass block fail block

Thanks for your time and help

[benny]

For me your configuration looks perfectly OK and what you described like a bug. I suggest you open a eSR with Alcatel-Lucent.

B

[TechBu]

Hi,

Thanks for the reply Benny!

We've contacted our business partner and they opened a ticket with ALU…

Meanwhile we've searched some more and we were finally been able to reproduce the error in our lab!! And after some tests, and monitoring for 6 days we’ve finally found a workaround! So here's a short description of what we've found, and what we've configured to avoid the problem;

The problem appears after a certain inactivity of the clients. This might be after:
1. A logout/sleep/hibernate
2. Clients who are disconnected from a hub (not directly on the 6520!)
3. Inactivity on a PC when its on (no packets send or received)

After x-minutes the MAC-address is flushed (by default 5min) from the mac-address-table. Then the “802.1x user table” port state changes from “authenticated” to “authenticated – CP in progress”.
So when the client wants to reconnect they are still in CP and thus receiving an address from the CP-DHCP-range. Therefore they cannot obtain an address from our DHCP-server, so they can only work local (if already logged in on that PC in the past)
Keep in mind we’ve configured nothing for the CP!!

We’ve found out that we can use the command “802.1x x/y captive-portal inactivity-logout disable” as a workaround… Now the clients were never (since 6 days) in the “CP in progress” state!

[benny]

Hi,

Thanks for sharing the feedback here.

I just reviewed the documentation and the "inactivity-logout" is by default "disable". I think it is good practice to leave it "disabled" if CP is not used at all.

Benny