Contents

Authentication Flow via AMF Security mini

Quick Tour > Authentication Flow via AMF Security mini

---

---

Authentication for AMF Application Proxy in AW+

This section explains the authentication flow of devices in the AMF application proxy configuration of AW+.

There are two components in the AMF application proxy of AW+, but since device authentication is handled by the whitelist feature, this section explains the AMF application proxy whitelist feature.

• AMF Application Proxy Whitelist
  
• AMF Application Proxy Blacklist
  

AMF Security miniperforms authentication in response to requests from managed AMF Members (edge nodes), but since these requests are routed through the AMF Master (proxy node), AMF Security mini communicates and authenticates with the AMF Master (proxy node).

Note

Displays the date and time when AMF Security mini and AMF Member last communicated.

The basic flow leading up to an AMF member (edge node) sending a request to AMF Security mini is as follows.

1. An AMF member (edge node) receives a packet from a device.
   
2. The AMF member (edge node) checks whether authentication has been performed for the source MAC Address of the packet from the device. If the device has been successfully authenticated, the AMF Member (edge node) forwards the packet according to the corresponding VLAN.
   
3. If the device has not been authenticated, the AMF Member (edge node) sends a request packet to the AMF Master (proxy node).
   
4. The AMF Master (proxy node) forwards the request packet received from the AMF Member (edge node) to AMF Security mini.
   

AMF Security mini verifies the authentication process for the device's MAC Address recorded in the request packet received from the AMF Master (proxy node), determines the appropriate network for connection or isolation, or decides to discard the request, and then sends the result back to the AMF Master (proxy node).

The authentication process of AMF Security mini is broadly categorized into four types: Device Authentication Data, Tag Authentication Data, UnAuth Group, and action. However, the action-based authentication process is not used in authentication via the AMF application proxy.

• Device Authentication Data
  The network (VLAN) to connect to is determined based on the security policy (Policy) of the Device ID (Device) associated with the MAC Address.
  

  Note

  The OpenFlow switch, switch port, and the “Indefinite expiration date” option configured in each policy are not supported.

• Authentication using Tag
  The VLAN to connect to is determined based on the policy set on the tag, not the policy of the device with which the MAC Address is associated.
  
• UnAuth Group
  For MAC Addresses that are not registered in Device Authentication Data, the connection destination VLAN is determined based on the policy set for the UnAuth Group.
  

Device Authentication is performed in the following order: Device Authentication Data, Tag Authentication Data, and UnAuth Group.

As an example, the following describes the behavior when both Device Authentication Data and an UnAuth Group are registered.

• Since the MAC Address “00:00:00:00:00:01” matches the Device Authentication Data for “Device ID: Device_A,” it is connected to VLAN100.
  
• Since the MAC Address “00:00:00:00:00:02” is not registered with AMF Security mini and does not match any registered Device Authentication Data, it is connected to VLAN200 as part of the UnAuth Group. Since the policy for the UnAuth Group does not specify a location or schedule, all devices (MAC Addresses) that are not registered with AMF Security mini are connected to VLAN200.
  

Authentication for AMF Application Proxy in TQ

This section explains the authentication flow for wireless devices in the AMF application proxy configuration of TQ.

AMF Security mini performs authentication in response to requests from managed TQ devices. However, for a wireless device to be able to communicate, both the authentication by the AMF application proxy (AMF Security mini) and the authentication configured in the VAP (multi-SSID) security settings must succeed.

Note

If a wireless device succeeds in authentication by AMF Security mini but fails in the authentication configured in the VAP security settings, the device will be displayed as “Authorized” on the Device > Connected Device List page of AMF Security mini. Therefore, the actual status of the wireless device does not match its display in AMF Security mini.

The basic authentication flow for wireless devices is as follows.

1. A wireless device connects to the wireless network of TQ.
   
2. TQ checks the authentication status of the source MAC Address of the wireless device. If a wireless device is successfully authenticated by both AMF Security mini and the VAP security settings, TQ forwards the packet according to the VLAN assigned to the device.
   
3. If a wireless device is not authenticated, TQ sends a request packet to AMF Security mini.
   
4. Once authentication by AMF Security mini succeeds, authentication configured in the VAP security settings is performed.
   

   Note

   When WPA Enterprise is used in the VAP security settings of TQ, the VLAN assigned to a wireless device varies depending on whether dynamic VLAN is disabled or enabled. For details, refer to Quick Tour About AMF Security mini > AMF Application Proxy Function of TQ and TQR / Behavior when using TQ dynamic VLAN.

AMF Security mini verifies the authentication process for the MAC Address of the wireless terminal recorded in the inquiry packet received from TQ, determines the network to connect to or isolate, or decides to discard the packet, and then sends the information to TQ.

AMF Security mini has four major authentication processes: Device Authentication Data, Authentication using Tag, UnAuth Group and Action.

• Device Authentication Data
  The network (VLAN) to connect to is determined based on the security policy (Policy) of the Device ID (Device) associated with the MAC Address.
  
• Authentication using Tag
  The VLAN to connect to is determined based on the policy set on the tag, not the policy of the device with which the MAC Address is associated.
  
• UnAuth Group
  For MAC Addresses that are not registered in Device Authentication Data, the connection destination VLAN is determined based on the policy set for the UnAuth Group.
  

  Note

  The following items configured in each policy are not supported: location, schedule, OpenFlow switch, switch port, and the “Set flow expiration to unlimited” option.

• Action
  Specify individual actions—discard, quarantine, or assign a destination VLAN—for wireless terminals that match the conditions of MAC Address, IPv4 Address, device, device tag, and connected network. It is possible to manually create actions similar to the ones provided by interacting applications.
  

The authentication process for wireless terminals is performed in the following order: action, Device Authentication Data, Ttag Authentication Data, and UnAuth Group.

As an example, the behavior in the case where Action, Device Authentication Data, and UnAuth Group are registered is shown.

• The MAC Address "00:00:00:00:00:01" is registered in both "Action ID: Drop" and Device Authentication Data of "Device ID: Device_A". If the device authentication processing meets the conditions of the action that is performed first and Drop(Block) is applied, subsequent authentication processing of Device Authentication Data is not performed.
  
• The MAC Address "00:00:00:00:00:02" matches Device Authentication Data of "Device ID: Device_B", so it is connected to VLAN101.
  
• Since the MAC Address “00:00:00:00:00:02” is not registered with AMF Security mini and does not match any registered Device Authentication Data, it is connected to VLAN200 as part of the UnAuth Group.
  

---

(C) 2025 Allied Telesis, Inc. All rights reserved.

C613-04200-00 Rev A

07 Oct 2025 12:05