★ A site encountered an issue where MAC Portal Transparent authentication failed to access the internet after the third wireless access

V7 AC connected in bypass mode to the core, and FIT AP uses local forwarding(less than 20 APs and a small number of terminals) service template: remote Mac-portal transparent authentication connected to the third-part authentication server.

(1) The terminal connects to the mac-portal transparent service template. The first portal authentication passes normally, and corresponding portal entries are created on the AC and the server side, allowing normal internet access.

(2) After the terminal disconnects from WiFi and reconnects, the mac transparent authentication is automatically triggered. The AC successfully creates mac entries, and the server side also has corresponding transparent entries.

(3) After disconnecting wifi for the second time and reconnecting, the terminal still has portal and mac entries on the AC, but it cannot access the internet (unable to open web pages or ping Google), and the portal authentication page does not pop up automatically.

1. First, compare with the official website mac-portal transparent authentication official reference materials: https://www.h3c.com/en/d_202303/1815239_294551_0.htm. For example, no abnormalities were found in the on-site configuration.

2. Since the on-site AC version is relatively old and uses local forwarding (older versions do not have portal host-check enable enabled by default), check whether command portal host-check enable is configured. It was found to be correctly configured.

3. Check whether idle-cut is configured for the mac and portal authentication domains corresponding to the mac-portal service template on the AC, and whether the time is within 1/3~1/2 of the DHCP lease period for wireless terminal services. It was found that idle-cut was not configured under the mac authentication domain, while the idle-cut time parameter configured under the portal authentication domain was the shortest at 1 min, which was unusual. Therefore, the on-site personnel were instructed to adjust the idle-cut time under the mac and portal authentication domains to 1/3~1/2 of the DHCP lease period for wireless terminal services. Testing revealed that the fault phenomenon remained the same.

4. Have the on-site team reproduce the test failure and observe whether the portal entry and MAC authentication entry on the AC are abnormal during the reproduction process (i.e., check for discrepancies in VLAN, IP address, username, etc.) using the following command:

display portal user username xxx
display portal user ip X.X.X.X
display mac-authentication connection user-mac xxx

No abnormalities were found.

5. Have the on-site team reproduce the failure again and enable the following debug collection on the AC. The collection process is as follows:

First, on the AC, use: display wlan client mac-address H-H-H to check whether the corresponding authenticated terminal"s client entry exists, whether it belongs to the correct VLAN, and whether it has obtained the correct IP address?
Then enter the following two commands on the AC to check the portal packet and radius packet counts before reproducing the authentication failure on the AC.

     display portal packet statistics
     display radius statistics

     debug portal error
     debug portal event
     debug portal packet
     debug radius all 
     debug radius error
    [AC] info en
     t m
     t d

     u d a
     u t m
     u t d

     display portal packet statistics
     display radius statistics

Based on the debug log information, it was found that the entire authentication interaction process had no issues. However, when the terminal connected to the WiFi for the third time, since the portal entry and mac entry already existed on the AC (if the portal entry has aged but the mac entry still exists, the mechanism is the same), only the terminal went online (i.e., the wireless association process) without any authentication interaction between the AC and the server.

Therefore, it is suspected that there may be no issue with the wireless itself, but rather some interaction between the authentication server and the egress security appliance. Each time a terminal connects to the wireless, the egress device creates a new session. After this session is established, the AC must send a Radius message (charging start or update) to the server to allow the egress security appliance to permit the wireless terminal"s access to external network addresses or domains during this session.

Based on this suspicion, first let the wireless terminal enter the state of connecting for the third time again, meaning the terminal cannot access the internet or open web pages at this point. Then ping an IP address on the internal network that is not allowed by the portal free-rule on the AC (the terminal is a mobile phone capable of installing the cloudnet APP for ping testing). It was found that the ping succeeded, but pinging external networks failed simultaneously. This proves that the AC and AP did not intercept due to MAC or portal authentication issues, and also confirms that the MAC-portal transparent mechanism on the AC is functioning correctly. Therefore, the connection from the terminal to the external network may be blocked by the egress device。

Since the local forwarding mode is used on-site, it is recommended to perform port mirroring capture on the downlink port of the POE switch connected to the AP or check where the terminal packets are intercepted via the switch"s traffic statistics. However, the customer feedback indicates that their egress firewall indeed has the mechanism mentioned in the red text above, which confirms our judgment. That is, each time the terminal re-associates with the wireless network, the egress device creates a new session. This session requires the AC to send a Radius packet for charging start or update to the server before allowing the terminal to access the external network.

Since the egress security appliance policy cannot be modified on-site, it is proposed that each time a terminal re-associates with the wireless network (including when the terminal disconnects and reconnects to WiFi, or when the terminal performs a roaming switchover between APs or radios), the AC must resend the charging start or update message.

To achieve this requirement, the client-security accounting-start trigger ipv4 mechanism enabled by default under the wireless service template was initially considered. However, this requires the IP address to change each time the terminal reassociates (the terminal obtains a new address) to trigger the AC to resend the charging update. Due to DHCP Server limitations, this cannot be implemented.

Therefore, terminals must re-authenticate via portal or MAC transparent authentication after each reassociation. This ensures the AC interacts with the server for Radius authentication and charging packets, enabling coordination with the egress firewall device.

Since the on-site deployment uses MAC-Portal transparent authentication, the characteristic of this method is that after the terminal passes the first Portal authentication and goes online, when connecting to WiFi for the second time, regardless of whether there is a Portal entry for this terminal on the AC, as long as there is no MAC entry, MAC authentication will be performed. Therefore, simply clearing the MAC entry on the AC when the terminal goes offline or roams out will suffice.

Since the wireless terminal MAC authentication entries on our company"s AC are linked with client cache entries, the following was added under the service template: client cache-aging time 0, this issue was resolved.

[Note] However, it should be noted that this method will trigger AC and server Radius authentication interaction every time the terminal reconnects to WiFi (including roaming). In scenarios with a large number of APs and terminals and frequent roaming, this will impose a significant burden on the server. Fortunately, this site has a limited number of APs and terminals, primarily for office use. A better approach would be to modify the mechanism of the security appliance at the egress to allow more reasonable access control for terminal traffic to the external network.

Added under the service template: client cache-aging time 0, Ensure that MAC authentication is triggered every time a wireless terminal reconnects to WiFi.