Chances are you going to need an radius Auth over WAN - because your Radius and Identity Mngmnt is hosted in the security of the local datacenter of your corp... but the client (i.e. an network switch) is somewhere over the rainbow WAN. You *could* just pipe the radius traffic over the internet - but there be dragons: radius communication is unencrypted. So... just no.

Enter radsecproxy: Radsecproxy is - as the name implies, an radius proxy - which needs to be installed on both servers (the local one in your company, now called SERVER, and the remote one with the switch attached, now called CLIENT) - and does encrypt the communication between both server parts (over WAN i.e.) via TLS.

1.) Install radsecproxy on Server ( sudo apt-get install radsecproxy )
2.) Create CA with generate-CA.sh (in /etc/radsecproxy/) [ https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh - please change keybits to 4096 bits, thanks! ]
3.) Create Certs (Server, Client) with generate-client.sh (in /etc/radsecproxy/) [ at the end of this post, http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt - please change keybits to 4096 bits as well! 🙂 ]
4.) Configure /etc/radsecproxy.conf [UPPERLETTERS are constants which you need to change]

# Master config file for radsecproxy
sourceTLS IPADDR_OF_SERVER
listenTLS IPADDR_OF_SERVER:2083

LogLevel 3
LogDestination file:///var/log/radsecproxy/radsecproxy.log

LoopPrevention on

tls default {
CACertificateFile /etc/radsecproxy/ca.crt
CertificateFile /etc/radsecproxy/SERVER_NAME_FQDN.crt
CertificateKeyFile /etc/radsecproxy/SERVER_NAME_FAQN.key
}

client CLIENT_NAME {
host IPADDR_OF_CLIENT
type tls
certificatenamecheck off
secret PW_OF_CLIENT_RADSEC
}

server SERVER_NAME_auth {
host IPADDR_OF_SERVER:1812
type udp
StatusServer on
secret PW_OF_SERVER_FOR_RADIUS
}

server SERVER_NAME_acct {
host IPADDR_OF_SERVER:1813
type udp
StatusServer on
secret PW_OF_SERVER_FOR_RADIUS
}

realm * {
server SERVER_NAME_auth
accountingserver SERVER_NAME_acct
}

# example config for localhost, rejecting all users
client 127.0.0.1 {
type udp
secret TEST_SECRET
}

realm * {
replymessage "User unknown"
}

5.) sudo service radsecproxy restart

6.) Install radsecproxy on Client ( sudo apt-get install radsecproxy )
7.) Copy client cert and ca.crt to Client /etc/radsecproxy
8.) Configure /etc/radsecproxy.conf [UPPERLETTERS are constants which you need to change]

#sourceUDP 127.0.0.1
sourceUDP IPADDR_OF_CLIENT
listenUDP *:1812
listenUDP *:1813

LogLevel 3
LogDestination file:///var/log/radsecproxy/radsecproxy.log

LoopPrevention on

tls default {
CACertificateFile /etc/radsecproxy/ca.crt
CertificateFile /etc/radsecproxy/CLIENT_NAME_FQDN.crt
CertificateKeyFile /etc/radsecproxy/CLIENT_NAME_FQDN.key
}

client CLIENT_NAME {
#host 127.0.0.1
host IPADDR_OF_CLIENT
type udp
secret CLIENT_RADIUS_SECRET
}

client SWITCH_NAME {
host SWITCH_IP
type udp
secret SWITCH_RADIUS_SECRET
}

server SERVER_NAME {
certificatenamecheck off
host IPADDR_OF_SERVER
type tls
StatusServer on
secret PW_OF_CLIENT_RADSEC
}

realm * {
server SERVER_NAME
accountingserver SERVER_NAME
}

# example config for localhost, rejecting all users
client 127.0.0.1 {
type udp
secret TEST_SECRET
}

realm * {
replymessage "User unknown"
}

9.) sudo service radsecproxy restart
10.) If you now point your switches to the CLIENT_IP with the correct credential, it should go via the radsecproxy to your main radius server and get the connection working. Please pay attention that on your CLIENT site no radiusd daemon is allowed to run, as it would block the ports needed for radsecproxy / radius. Make use of the radsecproxy log files to see, wheter the two radsecproxy servers do connect and talk to each other :).