Rublon Authentication Proxy RADIUS Modes Explained

Last updated on April 24, 2025

Rublon Authentication Proxy allows you to safely authenticate to your VPN or another service by enabling robust Multi-Factor Authentication (MFA) on all your log-ins. Depending on the authentication mode you set for the RADIUS Proxy server in the configuration file of the Rublon Authentication Proxy, your authentication will differ. This article describes all three available modes in the Rublon Authentication Proxy to try and help you select the mode that best suits your needs.

To change the mode that the Rublon Authentication Proxy operates in, open the configuration file of the Rublon Authentication Proxy and locate the mode option under the “proxy_servers” section. (Note that this option is only available for the “RADIUS” type of proxy server.) Then, set the mode option to one of the following values:

“standard” – allows you to log in using a predefined secondary authentication method or using Append Mode.
“challenge” – allows you to log in using Radius Challenge. Rublon Authentication Proxy will respond with the Access-Challenge packet and wait for the selected authentication method provided in the next request.
“nocred” – allows you to log in to specific system integration. The NoCred Mode only performs secondary authentication and should be used with systems that prompt you for an extra authentication step after performing the first factor on its own (like Awingu).

The mode option is set to “standard” by default. You can change the mode option at any point.

Read on to learn more about each Rublon Authentication Proxy mode.

Standard Mode

The Standard Mode is the default authentication mode in the Rublon Authentication Proxy. The user logs in using their username and password, which is the first authentication factor. Then, Rublon checks the auth_method option to select the authentication method to use during the second authentication factor.

The following snippet shows a part of the Rublon Authentication Proxy configuration file configured for the Standard Mode.

 "proxy_servers": [
    {
      "name": "RADIUS-Server",
      "type": "RADIUS",
      "radius_secret": "test-radius-secret",
      "ip": "0.0.0.0",
      "port": 1812,
      "mode": "standard",
      "auth_source": "LDAP_1",
      "auth_method": "push,email"
    }
  ],
  "auth_sources": [
    {
      "name": "LDAP_1",
      "type": "LDAP",
	 ...
    }
  ]

Note the following:

The mode option has been set to “standard” to enable the Standard Mode.
The auth_source has been set to “LDAP_1” (which was configured in the “auth_sources” section) to make Rublon pull users from Active Directory during the first authentication factor. You can add more than one auth_source by providing a unique name for each.
The auth_method option has been set to “push, email”, which means that Rublon will first try to use the Mobile Push authentication method as the second authentication factor. If Rublon does not succeed in using the Mobile Push method (e.g., the user hasn’t enrolled their Rublon Authenticator), the Email Link authentication method will be used instead.

The following image portrays a basic login scenario in the Standard Mode.

1. User provides their username and password.

2. Rublon checks the credentials against the authentication source, e.g., Active Directory. The user is rejected if the credentials do not match. In this example, the credentials match.

3. Rublon checks the auth_method option in the Rublon Authentication Proxy configuration file to look for the authentication method to use during secondary authentication. If none of the methods set in auth_method are available (e.g., they are deactivated by a Custom Policy in the Rublon Admin Console), the user is rejected. Let’s assume that in this example the auth_method option has been set to “push, email”.

4. If Mobile Push cannot be used by the user (e.g., they haven’t enrolled the Rublon Authenticator), Rublon sends an Email Link to the user instead. Let’s assume that Rublon detected that Mobile Push cannot be used and sent them an Email Link instead.

5. Rublon waits for the user to click the Email Link sent in an email message.

6. Rublon does some additional security checks. User is rejected if checks fail.

7. User is logged in to their service.

Append Mode

Append Mode is a Rublon Authentication Proxy mode that allows users to choose their authentication method by appending specific values to their password when logging in to an integrated service. The value they enter must be preceded by the append mode separator.

The Append Mode is available only if you set the mode to “standard” in your config.json file.

To enable Append Mode, you must add use_append_mode and append_mode_separator to one of your server’s configurations under the proxy_servers section:

  "proxy_servers": [
    {
      "name": "RADIUS-Server",
      "type": "RADIUS",
      "use_append_mode": true,
  	 ...
    }
  ]

When the user logs in, they can append one of the method names to their password. For a list of all available methods, refer to Rublon User Guide – Append Mode.

The following image depicts Append Mode used with the Passcode authentication method.

Challenge Mode

The Challenge Mode might be the preferred choice for services that support the Radius Challenge.

Services that support the Radius Challenge include but are not limited to:

The following snippet shows a part of the Rublon Authentication Proxy configuration file configured for the Challenge Mode.


  "proxy_servers": [
    {
      "name": "RADIUS-Server",
      "type": "RADIUS",
      "radius_secret": "test-radius-secret",
      "ip": "0.0.0.0",
      "port": 1812,
      "mode": "challenge",
      "auth_source": "LDAP_1",
      "auth_method": "push"
    }
  ],
  "auth_sources": [
    {
      "name": "LDAP_1",
      "type": "LDAP",
	 ...
    }
  ]

Note the following:

The mode option has been set to “challenge” to enable the Challenge Mode
The auth_source has been set to “LDAP_1” (which was configured in the “auth_sources” section) to make Rublon pull users from Active Directory during the first authentication factor. You can add more than one auth_source by providing a unique name for each.
The auth_method option has been set to “push”, which means that in case the method selected in the second step is not recognized, Rublon will send a Mobile Push authentication request to the user as the second authentication factor.

The following image portrays a basic login scenario in the Challenge Mode.

1. User provides the username and password.

2. Rublon checks the credentials against the authentication source, e.g., Active Directory. The user is rejected if the credentials do not match.

3. If credentials match, an input field is displayed to the user. The user can enter “push”, “email”, “123456” (the current value of the Passcode), “123456789” (the user’s Bypass Code), the YubiKey OTP, “smsLink”, or “phoneCall”. If the value entered by the user is not recognized, Rublon will use the authentication method set in the config.json file.

4. Let’s say the user wants to use the Mobile Push method.

5. User accepts the Mobile Push authentication request and is logged in to the service.

NoCred Mode

The NoCred Mode allows you to authenticate into your integrated service without having to provide the login and password information to Rublon. You still have to provide your password, but this process is all on the integrated services’ side, and Rublon has no say in it. Only after the first authentication factor has been accepted, the Rublon Authentication Proxy asks the user to choose the authentication method.

The NoCred mode is required for the following integrations:

Awingu

The following snippet shows a part of the Rublon Authentication Proxy configuration file configured for the NoCred Mode.


  "proxy_servers": [
    {
      "name": "RADIUS-Server",
      "type": "RADIUS",
      "radius_secret": "test-radius-secret",
      "ip": "0.0.0.0",
      "port": 1812,
      "mode": "nocred",
      "auth_method": "push"
    }
  ]

Note the following:

The mode option has been set to “nocred” to enable the NoCred mode
The auth_method option has been set to “push”, which means that in case the method selected in the second step is not recognized, Rublon will send a Mobile Push authentication request to the user as the second authentication factor.
Note that the type option for this auth_source is not set in this case. This is because primary authentication is not performed in this mode.

Refer to the following images presenting an example of basic NoCred authentication.

1. User provides their login and password. They log in to Awingu, and this process is not overseen by Rublon. The user is rejected if the credentials do not match. In this example, the credentials match.

2. User provides the name of the authentication method in an input field. Possible authentication method names are:

123456(789) – a Passcode (6-digit TOTP code generated by Rublon Authenticator or 9-digit Bypass Code)
push – a Mobile Push is sent to their phone; requires Rublon Authenticator
email – an email message containing an Email Link is sent to their email address
smsLink – an SMS Link is sent to their phone; requires a phone number to be configured
phoneCall – Rublon makes a Phone Call and asks them to press any key
<YubiKey OTP code> – the user inserts the YubiKey and presses the button on the key; the YubiKey OTP is typed and Enter is pressed automatically

3. Rublon receives the login request containing the username and the authentication method name provided in Step 2.

4. Rublon parses the authentication method name. If Rublon cannot find a proper authentication method name or Passcode, Rublon uses the authentication method set in the auth_method option in the configuration file. Let’s assume the user provided the authentication method name “push”.

5. Rublon recognizes that the user wants to use the Mobile Push method and sends them a Mobile Push authentication request.

7. User receives the Mobile Push authentication request and approves it.

8. User is logged in to their service.

Rublon Gives You The Diversity You Need

We hope that this article will help you to choose the best-fitting Rublon Authentication Proxy mode. Each mode comes with its unique set of capabilities and works well in a different use case scenario. While the Standard Mode should suffice in most cases, some integrations like Awingu or Cisco AnyConnect require a specific mode. If you have any questions about the Rublon Authentication Proxy, do not hesitate to contact our customer support team at Rublon Support. We are here to help.