Good Evening, We have several separate networks. Our main network runs PPPoE while all of the others run over DHCP. I would like to migrate the DHCP networks to use PPPoE. Currently, our Radius server resides at the head end of our PPPoE network. I would like to remove the chance that if the Internet failed there, that no one on the separate networks would be able to authenticate. Has anyone had any experience with using a Radius server in the cloud to authenticate users? Thank you very much, -- Michael Geary GAW High-Speed Internet 72 Shaker Rd. Enfield, CT 06082 www.GAW.com <http://www.gaw.com/> Office: 877.543.8429 Direct: 413.203.4911 Cell: 413.218.1446 Fax: 877.816.7068 netops@gaw.com -- “The information contained in this email message may be confidential. If you are not the intended recipient any use, distribution, disclosure or copying of this information is prohibited. If you receive this email in error, please tell us by return email and destroy this communication and any attachments from your system."
On Thu, Sep 27, 2012 at 5:42 AM, Michael Geary <mgeary@greataukwireless.com> wrote:
Good Evening,
We have several separate networks. Our main network runs PPPoE while all of the others run over DHCP. I would like to migrate the DHCP networks to use PPPoE.
Currently, our Radius server resides at the head end of our PPPoE network. I would like to remove the chance that if the Internet failed there, that no one on the separate networks would be able to authenticate.
Has anyone had any experience with using a Radius server in the cloud to authenticate users?
There's nothing magic about it, really. You need to decide what you want first. For example, on out setup. the NAS (i.e. BRAS) and other internal systems (including radius and billing) are connected using internal private network. We put radius servers on multiple locations, connected to that internal network. That way, if one radius location goes down, or even if the whole internet goes down, users will still be able to authenticate. Now when you say "radius in the cloud", it can either mean: - you have and manage radius servers in multiple locations accessible from internet. Again, nothing magic about this. It should just work provided you have ways to synchronize data between radius servers (e.g. using db replication or whatever). OR - someone else will manage radius service for you. There are companies that provide that, and it should work, though personally I haven't tried any of them. Either one should work, assuming you already know what you want and create a suitable design for it. -- Fajar
On 09/26/2012 11:42 PM, Michael Geary wrote:
Good Evening,
We have several separate networks. Our main network runs PPPoE while all of the others run over DHCP. I would like to migrate the DHCP networks to use PPPoE.
I assume these are Ethernet-over-ADSL lines and you want to move away from static DSLAM port config, and to @isp.com dynamic routing?
Currently, our Radius server resides at the head end of our PPPoE network. I would like to remove the chance that if the Internet failed there, that no one on the separate networks would be able to authenticate.
So the other networks have separate internet connectivity?
Has anyone had any experience with using a Radius server in the cloud to authenticate users?
Personally, I'd never do it. FreeRADIUS performs well on commodity hardware, so just build more RADIUS servers and put them in various locations e.g. one in each remote location. Presumably you have DHCP servers in those locations now - the same hardware would probably suffice, since the load should be approximately the same. However, as Fajar says, if you want to "cloud" it there's nothing magic - RADIUS is just UDP/IP packets, so running it in the cloud should work fine. Couple of things to watch out for: 1. RADIUS shared-secrets are keyed off source IP and destination IP/port. We occasionally see people who've painted themselves into a corner with NAT, or NASes on dynamic, unknown-prior IPs. Think carefully about how you'll avoid this issue, particularly if your NASes are on private IPs. This is not usually a problem over an internal network. 2. Normal radius doesn't encrypt (but does sign) the entire packet. Only selected fields like "User-Password" (and EAP payloads that are encrypted by the EAP method). Decide if you care about this - the RADIUS packet will contain things like user names, MAC addresses and so on, and they'll be flowing over an untrusted network. It's probably not a worry, but in the EU at least, I'd be concerned about data protection. In theory you can solve this with RADSEC. In practice, virtually no NAS supports RADSEC, so you are left with IPSec or some other VPN as an option, or just live with it. Likewise, not usually a problem over an internal network.
Thank you all for your input. I would be managing the Radius servers hosted by like HostGator or Rackspace or someone like that. On Thu, Sep 27, 2012 at 4:39 AM, Phil Mayers <p.mayers@imperial.ac.uk>wrote:
On 09/26/2012 11:42 PM, Michael Geary wrote:
Good Evening,
We have several separate networks. Our main network runs PPPoE while all of the others run over DHCP. I would like to migrate the DHCP networks to use PPPoE.
I assume these are Ethernet-over-ADSL lines and you want to move away from static DSLAM port config, and to @isp.com dynamic routing?
We are a fixed-terrestrial wireless internet service provider
Currently, our Radius server resides at the head end of our PPPoE network. I would like to remove the chance that if the Internet failed there, that no one on the separate networks would be able to authenticate.
So the other networks have separate internet connectivity?
Yes, they are located throughout Vermont, New Hampshire and Massachusetts
Has anyone had any experience with using a Radius server in the cloud to authenticate users?
Personally, I'd never do it. FreeRADIUS performs well on commodity hardware, so just build more RADIUS servers and put them in various locations e.g. one in each remote location. Presumably you have DHCP servers in those locations now - the same hardware would probably suffice, since the load should be approximately the same.
However, as Fajar says, if you want to "cloud" it there's nothing magic - RADIUS is just UDP/IP packets, so running it in the cloud should work fine.
Couple of things to watch out for:
1. RADIUS shared-secrets are keyed off source IP and destination IP/port. We occasionally see people who've painted themselves into a corner with NAT, or NASes on dynamic, unknown-prior IPs. Think carefully about how you'll avoid this issue, particularly if your NASes are on private IPs.
This is not usually a problem over an internal network.
2. Normal radius doesn't encrypt (but does sign) the entire packet. Only selected fields like "User-Password" (and EAP payloads that are encrypted by the EAP method). Decide if you care about this - the RADIUS packet will contain things like user names, MAC addresses and so on, and they'll be flowing over an untrusted network. It's probably not a worry, but in the EU at least, I'd be concerned about data protection.
In theory you can solve this with RADSEC. In practice, virtually no NAS supports RADSEC, so you are left with IPSec or some other VPN as an option, or just live with it.
Thank you, I was thinking of connecting them to the internal networks via OpenVPN or IPSec
Likewise, not usually a problem over an internal network.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
On Thu, Sep 27, 2012 at 9:34 PM, Michael Geary <mgeary@greataukwireless.com> wrote:
I would be managing the Radius servers hosted by like HostGator or Rackspace or someone like that.
So the other networks have separate internet connectivity?
Yes, they are located throughout Vermont, New Hampshire and Massachusetts
In theory you can solve this with RADSEC. In practice, virtually no NAS supports RADSEC, so you are left with IPSec or some other VPN as an option, or just live with it.
Thank you, I was thinking of connecting them to the internal networks via OpenVPN or IPSec
Two last comments from me: (1) I assume you already have a plan on how to keep your users data synchronized between the servers? There are many ways to do this, like db replication, LDAP multi-master replication, or even plain-old rsync of users file. Accounting is somewhat similar, but since (depending on your setup) it's probably easier since you don't have to keep them synchronized. It might be enough to just pull accounting data from all servers regularly to do centralized processing. (2) openvpn is good, but in my experience I had trouble reconnecting after network failure if openvpn is run on udp (the default). Using tcp doesn't have this problem (although it introduce other problems, like longer retries, which in my case was acceptable). -- Fajar
participants (3)
-
Fajar A. Nugraha -
Michael Geary -
Phil Mayers