Reset Search



KB44388 - Understanding PPS RADIUS proxy types

« Go Back


Last Modified Date3/9/2020 4:03 PM
The PPS admin guide has detailed instructions on how to create a RADIUS Auth Server entry and discusses the advantages of each proxy type. After selecting a RADIUS Auth Server in a realm you are presented with three options. It is these three options, how they work, and what you should expect when using them that this KB will focus on.

Problem or Goal
A message about proxy limitations:
When RADIUS proxy is used, realm or role restrictions cannot be enforced. Host Checker policies, Source IP restrictions, and any other limits that have been assigned will fail.  Use RADIUS proxy only with realms and roles that have no restrictions. See screen shots below, red arrows used to indicate restrictions that are not usable with RADIUS proxy and that may result in authentication failure.
Part 1 The Outer Proxy
Authentication Flow:
  1. The PPS forwards everything to the external RADIUS server and does not inspect the credentials at all.
  2. All attributes from the RADIUS client are sent to the external RADIUS server as well, attributes such as NAS-IP-Address and calling-station-ID.
  3. It is the external RADIUS server that presents its certificate to the supplicant and negotiates the tunneled EAP protocol in the case of 802.1x
  4. If successful, the external RADIUS server sends an access accept and any return attributes the proxied user is assigned.
  5. The PPS forwards the response from the external RADIUS server to the RADIUS client including all the return attributes.
In short, the PPS acts as a relay between the RADIUS client and the external RADIUS server.
Note: !!!An outer proxy will fail if the realm is part of a sign-in URL that includes any other realms!!!
  • In the case of an 802.1x authentication, it is the external RADIUS server’s certificate that is presented to the supplicant during mutual authentication not that of the PPS, ensure the supplicant has the necessary certificates installed to validate the external server.
  • The PPS does not monitor users authenticated via an outer proxy; the user will not appear in Active Users. No session is created on the PPS.  
  • The PPS cannot process any role mapping rules based on the username or directory lookup as the PPS is unaware of the user’s credentials.
Protocols Supported: All protocols supported by the external RADIUS server

Part 2 The Inner Proxy
Authentication Flow:
  1. The PPS evaluates the incoming request and determines which realm it should be sent to. If sent to the realm configured for an inner proxy, the PPS decrypts the TLS tunnel in the case of 802.1x.
  2. For 802.1x the tunnel exists between the PPS and the supplicant.
  3. The PPS then sends the credentials to the external RADIUS server which will result in a success or failure.
  4. If successful, the PPS can perform role mapping as with an inner proxy the PPS is aware of the user’s name.
  5. Any return attributes are defined on and returned by the PPS.
  6. A session is created.
  • With the inner proxy it is the PPS device certificate that the supplicant may need to validate in the case of 802.1x.
  • With an inner proxy it is the PPS that assigns any return attributes.
  • In the case of 802.1x it is the PPS that negotiates the outer protocol and inner protocol in the case of 802.1x.
Protocols Supported: TTLS, PEAP, PAP, CHAP, EAP-MD5, MS-CHAP, and MS-CHAPv2

Part 3 Do Not Proxy
The name of this option can be misleading. “Do Not Proxy” means that the PPS will manage all aspects of the authentication which include…
  • Negotiating the protocol
  • Sending its certificate for mutual authentication
  • Establishing a TTLS, TLS, or PEAP tunnel if 802.1x is used
  • Negotiating the inner protocol if 802.1x
  • Perform role-based access control, as with an inner proxy, the PPS knows the username
  • Supply any return attributes the user is assigned
The external RADIUS server only validates the user’s credentials. The PPS will use PAP to send the user credentials to the external RADIUS server.
For a Do Not Proxy to be successful, the incoming authentication request that is to be proxied must have the user’s password in clear text. This means PAP. In the case of 802.1x the supplicant must use PAP, or JUAC. The external RADIUS server will need to validate the plain text password. This means that the database the password resides in must have the password stored in either plain text or us reversable encryption.
Related Links
Attachment 1 
Created ByBrian Pimentel



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255