A while back I documented a procedure to allow RADIUS Authentication for Cisco Router Logins. Shortly thereafter I included additional instructions on how to Set Up Windows 2003 IAS Server with RADIUS Authentication for Cisco Router Logins. This updated post will discuss the configuration of a Windows 2008 R2 server for Cisco router logins using RADIUS authentication. In my example I will install the Network Policy Server to support RADIUS on a Windows 2008 R2 domain controller and give router login access to an Active Directory domain user.
First go into Server Manager.
Highlight Roles on the left side, then in the Role Summary section click Add Roles on the far right.
When you reach the Select Server Roles screen, check Network Policy and Access Services. Click Next.
Check Network Policy Server only, then click Next. Then click Install and and confirm the install was successful.
One of great things about the syslog logging standard is the capability to collect system notifications from a variety of network hosts and direct them to a central store for analysis. In this demo I will configure a Cisco router to log system messages using syslog to a central Linux server. Specifically I am interested in logging authentication attempts to the router.
My preferred syslog daemon that I will be running on my Linux syslog server is rsyslog. There are also many syslog servers available for Windows if you choose to go that route. Kiwi is one with a nice interface but the full featured version is payware. Your choice of a syslog server to collect your messages should be immaterial to this discussion as the configuration steps should be the same on a Cisco router.
Configure Syslog Server to Accept Messages
To start, we’ll make sure that the syslog server is configured to accept messages from the IP address of your router. This should be the IP of the interface on the router that is closest to the syslog server. For example, suppose the router has an external and an internal interface. Our syslog server is on the same LAN that the internal interface is connected to. The syslog server should be configured to accept messages from the IP address of the internal interface. We also have the option to manually configure the interface the syslog messages are sourced from.
The syslog standard sends log messages identified with a certain facility and severity. Generally the facility is used to identify the message as coming from a particular program or service. This has more use when the source of the syslog messages is a full blown computer server. In the case of Cisco routers by default syslog messages are sent marked as coming from the “local7” facility, so we need to make sure that the syslog server accepts messages from this facility. The source facility can be changed if you so desire.
In addition, syslog messages have a severity attached which gives information on the priority or urgency of the message. If you are familiar with syslog you know that higher numbers represent lower severity levels. Here is a list of the minimum severity levels that a Cisco router can be configured with which to send messages to the syslog server.
Router(config)#logging trap ? <0-7> Logging severity level alerts Immediate action needed (severity=1) critical Critical conditions (severity=2) debugging Debugging messages (severity=7) emergencies System is unusable (severity=0) errors Error conditions (severity=3) informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4)
Recently I had the desire to start monitoring the statistics of our internet router. The main thing that I wanted to measure was the volume of traffic passing in from and out to the internet because the ISP limits the amount of data passing over the connection for each month. With a tool such as Cacti we can collect these statistics via SNMP and graph them in a fairly simple way. For details on how to set up an instance of Cacti on a CentOS Linux server go here.
Configure SNMP on Cisco Router
Go into global config mode:
cisco1# conf t
First we’ll set up read only access for a community string named “TestCommunity”. The community string functions like a password and only allows access for management stations configured with the same string name. Bear in mind that this value is passed over the network unsecured so do this only on private networks.
cisco1(config)# snmp-server community TestCommunity ro
For now Cacti will only need read access to get SNMP access stats. Make a note of the community string because we’ll need to configure the Cacti server with this later.
In a previous post I discussed configuring an IPsec VPN between a Cisco router and a Windows PC with the Cisco VPN client installed. Today I’ll expand on this by configuring the VPN to utilize the RADIUS protocol to authenticate VPN users. This will ease administration and will allow users access to their VPN sessions using their directory services user accounts. For the RADIUS server I will use a Windows Server 2003 R2 that is part of an Active Directory domain with the IAS service installed. The IAS service can be just as easily configured with local user accounts on the Windows workgroup server if desired. When I first started implementing this I had great difficultly getting the IPsec VPN to work with RADIUS, I guess the IOS configuration commands can be a bit tricky. But now it just keeps on working!
Configure the Cisco Router IOS
In this example my router is configured as in the example Configure Cisco Router for Remote Access IPsec VPN Connections. Run through that article and come back here once you’ve completed it.
Next we need to modify AAA to allow user authentication using the RADIUS server.
R1# conf t R1(config)# aaa authentication login VPN_CLIENT_LOGIN group radius local
Now we need to add the RADIUS server. Specify the IP address and a key to use.
R1(config)# radius-server host 192.168.2.4 auth-port 1645 acct-port 1646 key RadiusKey
That’s it for the configuration in the Cisco IOS. Now let’s move over to the Windows 2003 IAS configuration.
Configure Windows Server 2003 IAS RADIUS Service
If you have previously read my article Set Up Windows 2003 IAS Server with RADIUS Authentication for Cisco Router Logins, you have a Windows IAS server already set up and the configuration should be able to authenticate your IPsec VPN connections. One thing that I have noticed is that my IPsec VPN authentication does not work when I have the IAS service installed on a domain controller. If the IAS service is installed on a domain member server the VPN connections do work fine. To configure the Windows IAS service follow these steps:
On a domain controller go into Start > Admin Tools > Active Directory Users and Computers. Optionally you can create a new group and add users to it that you want to grant router login access. In this example I will grant access to the existing Domain Admins user group.
Now double click a user account that you want to provide router login capability. I will use the Administrator account.
In the user properties dialog click the Dial-in tab, then make sure that Remote Access Permission is set to “Allow access”. You can also set this to “Control access through Remote Access Policy”, in which case the user account will be granted permission by its group membership that will be specified in the policy. Since we’ll specify a group in the Remote Access Policy, the above step actually should not be necessary. Click OK.
Recently I was testing Cisco’s CiscoSecure ACS 4.2 for RADIUS authentication for Cisco VPNs. The ACS server is configured through a web browser. I could start the browser and get into the management web site, however when I tried to add an AAA/RADIUS client I would receive the message “Add AAA Client Errors”:
What really perplexed me was the warning that the “Shared Secret” was blank, when in fact I had entered a value for it.
Turns out that you need to have the Java Runtime installed for the management web site to work properly. Once that was install, everything worked great.
Go here to download the Java Runtime Environment:
In this article I’ll walk through the configuration of the IOS on a Cisco router to support remote access IPsec VPN connections. IPsec is a suite of protocols that provides for authentication and encryption of packets. Traditionally PPTP has been extensively used as a VPN because of it’s simplicity of configuration, especially on the client side. However, the security vulnerabilities of the PPTP protocol have been well documented. Cisco now has a feature called EasyVPN that allows us to specify client configuration on the server and minimize direct configuration of the VPN on the client.
In this example I will make use of the fantastic GNS3/Dynamips software for router emulation. I’ve had some difficulties with IPsec and the Dynamips emulator, the VPN connection will start and work for a short time but then the connection will freeze. I have tested this configuration and it does work on a physical router, however.
I have set up my Cisco router with two interfaces, FastEthernet0/0 and FastEthernet0/1. The router is also configured with NAT overload for the internal network. Here is my network diagram, pretty basic configuration with an external and an internal network:
Here is my starting configuration of the router. Basically I’ve assigned IP addresses to the interfaces, configured the default route, and activated NAT. I’m using an extended access list to permit NAT traffic, this will be important later because we’ll need disable NAT between the internal interface and the IP address pool that our VPN clients will use.
! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname R1 ! boot-start-marker boot-end-marker ! no aaa new-model memory-size iomem 5 ip cef ! ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 ! interface FastEthernet0/0 ip address 192.168.10.2 255.255.255.0 ip nat outside ip virtual-reassembly speed 100 full-duplex ! interface FastEthernet0/1 ip address 192.168.2.254 255.255.255.0 ip nat inside ip virtual-reassembly duplex auto speed auto ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 192.168.10.254 ! ip http server no ip http secure-server ip nat inside source list NAT interface FastEthernet0/0 overload ! ip access-list extended NAT permit ip any any ! control-plane ! line con 0 line aux 0 line vty 0 4 ! end
In this installment we’ll run through the configuration of a Cisco router to support PPTP VPN remote access clients. Much has been documented in the last decade over the the weaknesses of using a PPTP VPN in combination with MS-CHAP-V2 for authentication, which is a commonly supported and simpler configuration. Namely, PPTP/MS-CHAP-V2 relies on a strong user password to be used to limit the ability of hackers to compromise the VPN session. The advantage of using the PPTP VPN is that it is fairly simple to set up and will allow Windows and Mac clients to access our secured network without installing the Cisco VPN client software. More secure configurations of PPTP are available using EAP-TLS for the authentication, these involve configuring client certificates and are beyond the scope of this article. In a future posting I plan to discuss the set up a more secure IPSec based VPN with a Cisco router.
In this example I will make use of the fantastic GNS3/Dynamips software for router emulation. I have set up a router with the NM16-ESW adapter to give the router basic switching functionality to test with an internal VLAN. The router is also configured with NAT overload for the internal network. Here is my network diagram, pretty basic configuration with an external network and an internal VLAN network: