Radiator Server Documentation — v10.34.1

RADIUS Proxying

Radiator can forward an incoming RADIUS exchange to a RADIUS backend. Direct proxying preserves the request and reply lifecycle while adapting each packet to the destination transport and packet profile.

RADIUS query mode builds a separate request from explicit bindings and maps its reply through explicit mapping statements. Use query mode when a policy must construct an independent RADIUS exchange or call RADIUS from another protocol. See RADIUS backend queries.

The RADIUS PROXY protocol is unrelated. It carries connection metadata, such as an original client IP address, at the transport layer. See PROXY protocol support.

Packet conversion

Direct proxying prepares the backend request before @pre-proxying runs. It converts supported attributes for the backend packet profile and shared secret. After the backend replies, Radiator prepares the downstream reply before @post-proxying runs.

Use these namespaces in the pipelines:

  • radiusproxy.request is writable in @pre-proxying.
  • radiusproxy.reply is writable in @post-proxying.

Proxy pipelines

Actions run in configuration order.

copy keeps values selected by its rules. filter removes values selected by its rules. If an action fails, Radiator stops the pipeline and does not send the packet.

This request pipeline removes tunnel attributes, adds Operator-Name, and selects the attributes sent to the backend:

@pre-proxying {
    filter {
        Tunnel-Type;
        Tunnel-Medium-Type;
        Tunnel-Private-Group-ID;
    }

    modify {
        radiusproxy.request.attr.Operator-Name = "4EXAMPLE_COM:FI";
    }

    copy {
        User-Name;
        User-Password;
        Operator-Name;
    }
}

This reply pipeline selects backend attributes, changes Reply-Message, and removes Vendor-Specific:

@post-proxying {
    copy {
        Reply-Message;
        Class;
        Vendor-Specific;
    }

    modify {
        radiusproxy.reply.attr.Reply-Message = "Processed by proxy";
    }

    filter {
        Vendor-Specific;
    }
}

Packet profiles and protected attributes

Radiator transforms protected and salted dictionary attributes as logical values. It decodes RADIUS/1.0 protection with the source authenticator and shared secret. It then applies the protection required by the destination packet profile and shared secret. RADIUS/1.1 carries the underlying value inside TLS.

This behavior applies to attributes such as User-Password, Tunnel-Password, and Microsoft MPPE keys. Tags remain attached to their logical values. Comparison rules inspect the decoded logical value instead of RADIUS/1.0 ciphertext.

Radiator does not copy a source Message-Authenticator into the outgoing packet. Finalization creates the value required for the destination hop and the completed attribute set. Request authenticators and RADIUS/1.1 tokens are also owned by the destination connection.

Dictionary-unknown attributes are forwarded by default when their wire representation can be preserved safely. Set proxy_unknown_attributes false to drop them. Unsafe conversion between RADIUS/1.0 and RADIUS/1.1 still fails.

EAP forwarding

Malformed EAP in an authenticated backend Access-Accept or Access-Reject is retained on receive but rejected on outgoing construction by default. Configure eap-message-validation on both the backend server and downstream server to permit unchanged forwarding. Requests, challenges, locally processed EAP and policy-created or modified EAP retain strict validation.

Multi-round authentication and State

An Access-Challenge can contain backend-owned State. Radiator stores the latest backend value for the active proxy exchange. The backend may replace or omit this value in each challenge.

Radiator removes backend-owned State from the client-facing challenge. It creates a separate proxy-owned downstream State that routes the next client request to the active proxy task. Before sending that continuation request, Radiator replaces the downstream value with the latest backend-owned value.

The exchange remains on the selected backend after the first challenge. If that backend fails after affinity has been established, Radiator terminates the exchange instead of retrying it on another server.

Proxy-State is separate from State. Proxy-State is hop-by-hop data added and removed by RADIUS proxies. It does not identify Radiator's active multi-round exchange.

When multiple Radiator instances accept requests, continuation requests must return to the instance that owns the proxy exchange state.