radsecproxy: News

radsecproxy is a generic RADIUS proxy that in addition to to usual RADIUS UDP transport, also supports TLS (RadSec), as well as RADIUS over TCP and DTLS. The aim is for the proxy to have sufficient features to be flexible, while at the same time to be small, efficient and easy to configure.

The proxy was initially made to be able to deploy RadSec (RADIUS over TLS) so that all RADIUS communication across network links could be done using TLS, without modifying existing RADIUS software. This can be done by running this proxy on the same host as an existing RADIUS server or client, and configure the existing client/server to talk to localhost (the proxy) rather than other clients and servers directly.

There are however other situations where a RADIUS proxy might be useful. Some people deploy RADIUS topologies where they want to route RADIUS messages to the right server. The nodes that do purely routing could be using a proxy. Some people may also wish to deploy a proxy on a site boundary. Since the proxy supports both IPv4 and IPv6, it could also be used to allow communication in cases where some RADIUS nodes use only IPv4 and some only IPv6.

Latest:

On October 25th 2012 radsecproxy-1.6.2 (PGP-sig) was released, and this is the recommended release for most people. Please report issues, request features etc. to the mailing list or the bug tracker. If you use it, you should consider joining the mailing list to stay up to date on changes, issues etc. as well.

1.6.2

Bug fixes (security):

• Fix the issue with verification of clients when using multiple 'tls' config blocks for DTLS too (RADSECPROXY-43, CVE-2012-4566). Reported by Raphael Geissert.

1.6.1

Bug fixes (security):

• When verifying clients, don't consider config blocks with CA settings ('tls') which differ from the one used for verifying the certificate chain (RADSECPROXY-43, CVE-2012-4523). Reported by Ralf Paffrath.

1.6

Incompatible changes:

• The default shared secret for TLS and DTLS connections change from "mysecret" to "radsec" as per draft-ietf-radext-radsec-12 section 2.3 (4). Please make sure to specify a secret in both client and server blocks to avoid unwanted surprises. (RADSECPROXY-19)
• The default place to look for a configuration file has changed from /etc to /usr/local/etc. Let radsecproxy know where your configuration file can be found by using the `-c' command line option. Or configure radsecproxy with --sysconfdir=/etc to restore the old behaviour. (RADSECPROXY-31)

New features:

• Improved F-Ticks logging options. F-Ticks can now be sent to a separate syslog facility and the VISINST label can now be configured explicitly. This was implemented by Maja Gorecka-Wolniewicz and Paweł Gołaszewski. (RADSECPROXY-29)
• New config option PidFile. (RADSECPROXY-32)
• Preliminary support for DynamicLookupCommand added. It's for TLS servers only at this point. Also, beware of risks for memory leaks. In addition to this, for extra adventurous users, there's a new configure option --enable-experimental-dyndisc which enables even more new code for handling of dynamic discovery of TLS servers.
• - Address family (IPv4 or IPv6) can now be specified for clients and servers. (RADSECPROXY-37)

Bug fixes

• Stop the autoconfery from warning about defining variables conditionally and unconditionally.
• Honour configure option --sysconfdir. (RADSECPROXY-31)
• Don't crash on failing DynamicLookupCommand scripts. Fix made with help from Ralf Paffrath. (RADSECPROXY-33)
• When a DynamicLookupCommand script is failing, fall back to other server(s) in the realm. The timeout depends on the kind of failure.
• Other bugs. (RADSECPROXY-26, -28, -34, -35, -39, -40)

For further information, see the download, documentation and contact pages.