Troubleshooting: RADIUS Logs Show the VPN Gateway's IP Address Instead of the Client's

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: All
     
     

    Overview

    When SecureAuth IdP uses RADIUS to authenticate users connecting through a VPN, the RADIUS authentication logs can show the VPN gateway's own IP address, or 127.0.0.1, as the UserHostAddress instead of the actual client's IP address. There are two common causes, depending on the VPN vendor in use:

    • See Cause 1 - The VPN gateway is Palo Alto Networks GlobalProtect
    • See Cause 2 - The VPN client is Cisco, or another VPN client that doesn't pass Calling-Station-Id by default

    These causes are not related, so a fix for one cause will not resolve the other.

     

    In this article


     

    Cause 1: Palo Alto Networks GlobalProtect Does Not Send the Standard Client-IP Attribute

    GlobalProtect does not send the client's IP address using the standard RADIUS attribute Calling-Station-Id. Palo Alto Networks PAN-OS v7 and later includes a separate RADIUS attribute, PaloAlto-Client-Source-IP, that carries the client's IP address instead. This attribute must be enabled on the Palo Alto Networks side, then pointed to from the SecureAuth RADIUS Server configuration.

     

    Resolution 1:

    1. On the Palo Alto Networks appliance, connect to the administration shell and run:
    set authentication radius-vsa-on client-source-ip
    1. On the SecureAuth RADIUS Server, go to the RADIUS Clients tab and change the RADIUS End User IP field to PaloAlto-Client-Source-IP, then save.

    SecureAuth RADIUS Server's Edit RADIUS Client page, showing the RADIUS End User IP field set to PaloAlto-Client-Source-IP.

    The realm's own audit logs still show UserHostAddress as the RADIUS Server's own IP address (127.0.0.1 if the RADIUS Server is installed on the same machine as the IdP) — this is expected, and does not mean the fix didn't work. Adaptive Authentication, and the RADIUS Server's own logs, both correctly use the real client IP address once this attribute is configured:

    A SecureAuth debug log excerpt showing UserHostAddress as 127.0.0.1 on each line, while the AnalyzeEngine geo-velocity check correctly evaluates the real client IP address instead.


     

    Cause 2: Cisco VPN Client Not Configured to Send Calling-Station-Id

    Most VPN clients, including Cisco's, don't send the connecting user's real IP address to the RADIUS server by default — SecureAuth IdP RADIUS Server logs instead show UserHostAddress as 127.0.0.1 for every user. This happens because the VPN client isn't configured to populate the standard RADIUS attribute Calling-Station-Id with the client's IP address.

     

    Resolution 2:

    Enable and configure Calling-Station-Id on the VPN client, or VPN concentrator, so its value is passed through to the RADIUS server. This is entirely a VPN client-side configuration change — nothing needs to be configured on the SecureAuth side for this cause.


     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.