Verizon Wi-Fi Calling: RADSEC and RADIUS Configuration Requirements

Overview

Verizon Wi-Fi Calling integrations rely on RADSEC (RADIUS over TLS) rather than standard unencrypted RADIUS, along with several attribute and formatting requirements that differ from other carriers. Getting these details right the first time avoids a common set of authentication failures.

Requirements and common issues

1. RADSEC (RADIUS over TLS) must be properly configured

Verizon requires RADIUS traffic to be secured via RADSEC rather than plain RADIUS. Confirm your controller supports and is configured for RADSEC specifically for the Verizon RADIUS server connection, including correct TLS version support (TLS 1.3).

2. Outbound firewall access for RADSEC

RADSEC typically communicates over TCP port 3003. Confirm this port is allowed outbound from your controller/APs to the RADIUS server — a blocked port here will prevent the connection entirely, even if all other configuration is correct.

3. Required RADIUS session/accounting attributes

Verizon authentication can fail if certain session or accounting attributes aren't being sent correctly. Confirm your controller is configured to include the required session ID attribute in RADIUS accounting packets.

4. MAC address formatting

Verizon expects a specific MAC address format in RADIUS requests. If your controller's default MAC formatting doesn't match what Verizon expects, authentication can fail even though the request reaches the server. Check your controller's RADIUS/AAA settings for a MAC address format option and confirm it matches Verizon's required format.

5. Idle timeout settings

Set an appropriate idle timeout value for RADIUS sessions — a value that's too short or left at a default not suited for voice/data sessions can cause premature session termination.

6. Check for CLI authorization lists that may silently block clients

Some controllers allow an authorization method list to be configured via CLI, separate from the main AAA/RADIUS configuration in the UI. If AAA override is enabled but an outdated or overly restrictive authorization list still exists in the CLI configuration, it can silently block clients even when the main RADIUS configuration looks correct. Check for and remove any legacy authorization lists that aren't part of your current intended configuration.

Troubleshooting steps (for your network/IT team)

1. Confirm RADSEC is enabled and using the correct TLS version for the Verizon RADIUS connection.
2. Confirm outbound TCP 3003 (or whichever port your RADSEC implementation uses) is allowed through your firewall.
3. Review RADIUS accounting configuration for required session/attribute settings.
4. Check and correct MAC address formatting in your RADIUS/AAA configuration.
5. Review idle timeout settings for RADIUS sessions.
6. Check your controller's CLI configuration for any authorization method lists that might be overriding or conflicting with your intended AAA/RADIUS setup.

7. Test live with a Verizon device to confirm authentication succeeds end-to-end.

    

If the issue continues

If you've verified all of the above and still see authentication failures, contact support with:

• Your controller platform
• Confirmation of what you've checked from the list above
• Any error messages visible in your controller's authentication logs

Our team can work with your network admin to review the RADSEC and RADIUS configuration in more detail.