Hi all. I have recently installed a WIFI lan in my department with 31 AP Huawei AP5130DN that communicate through a VLAN with the AC mentioned in the subject. I was wondering if anyone has got experience in setting up and configuring such an environment with freeradius. The AP are connected to six HP S3600 switches that send traffic to an aggregation switch to which the AC is connected through one of its Gigabitethernet interfaces. The AC has been setup to do 802.1x PEAP authentication through one FR server. root@bigserver:~# radiusd -v radiusd: FreeRADIUS Version 3.0.12, for host i686-pc-linux-gnu, built on Dec 13 2016 at 01:58:57 FreeRADIUS Version 3.0.12 Copyright (C) 1999-2016 The FreeRADIUS server project and contributors The AC has 2 VLANs: 1 e 300 (same as all the aforementioned switches). All relevant Gigabitethernet interfaces both on the switches and on AC are link-type HYBRID with tagged VLAN 300 and untagged VLAN 1. VLAN 300 is the management VLAN and all APs communicate with the AC through CAPWAP protocol on VLAN 300. VLAN 1 is the service VLAN and has layer 3 VLANIF 1 with IP 192.168.2.43 VLANIF has also ACL2000 with NAT rule 5: permit source 172.32.1.0 0.0.0.255 172.32.1.0 is the layer 3 ip address of VLAN 300 (AC is 172.32.1.1 on the inbound interface). AC and FR ping with no problems each other (192.168.2.43 <-> 192.168.2.1). Freeradius is configured to listen to 192.168.2.1 on standard UDP port 1812 and 1813. 192.168.2.1 is also the ETH0 interface ip address of the linux server it was configured on. AC is also configured for accounting through FR. Everything is working fine, meaning that FR *IS* capable of doing PEAP with sql, accounting and simultaneous-use properly configured. The only persistent problem are traffic bottlenecks between the FR and the AC. Very rarely the packets for completing the PEAP whole auth cycle are exchanged subsequently; more often the AC stops sending packets after the first or second Access-Challenge is sent by FR. In a very low traffic scenario the situation happens less frequently and authentications succeed almost normally. As soon as users number increases the UDP traffic slows down and users experience unacceptable authentication delays. The VAP forward mode is tunnel and NOT direct Forward mode. I do not attach here radiusd -X output because the problem IS NOT in FR configuration: like I said, PEAP authentication between AC and FR CAN succeed. Of course I am more than willing to do it if I'll be asked to do so. My problem is something hindering the UDP packet flow communication between 192.168.2.1 (freeradius) and 192.168.2.43 (AC). I am writing to the list in the hope that someone has already dealt with same equipment and possibly run into the same problem. Any help and/or attention to my situation would be highly appreciated. How could I for example debug the traffic flow regarding AAA on the AC? Am I facing some trivial timeout issues or what is actually causing this hindrance? Is EAPOL taking place in the CAPWAP tunnel if the VAP is configured to do tunnel forwarding mode? What do I have to configure in order to establish some traffic priority for the communication between AC and FR (both EAPOL and UDP traffic)? I've been struggling with this issue for almost 1 month now, and I really am in desperate need of someone familiar with my operating environment. Thanks for your time and attention. MacGherl60