Hello Jeremy,

Thank you for your interest in VMware beta programs. Our upcoming release of VMware Converter 4.0 Standalone product includes many exciting enhancements that our customers have been requesting including P2V support for Linux and Win 2K8 sources, hot cloning enhancements as well as workflow automation enhancements. We are certain you will find participation in this beta program a valuable experience. We are looking forward to working closely with you during this beta program.

As part of this beta, we request you to extensively test several areas of feature enhancements including P2V support for Linux and Win 2K8 sources, hot cloning enhancements as well as workflow automation enhancements. Your active participation in this beta program is critical. We appreciate and value your efforts to install upon downloading the software and actively provide us with your valuable product feedback.

I’m just about (in the next week or so) to attempt to P2V a Red Hat Enterprise Linux 4 host over to ESX, so maybe I’ll give the new 4.0 beta a shot. Anyone used it yet, especially to P2V Linux hosts? I am, of course, interested in hearing feedback on it.

“There is a delicious irony in seeing private luxury jets flying into Washington, D.C., and people coming off of them with tin cups in their hand, saying that they’re going to be trimming down and streamlining their businesses,” Rep. Gary Ackerman, D-New York, told the chief executive officers of Ford, Chrysler and General Motors at a hearing of the House Financial Services Committee.

“It’s almost like seeing a guy show up at the soup kitchen in high hat and tuxedo. It kind of makes you a little bit suspicious.”

He added, “couldn’t you all have downgraded to first class or jet-pooled or something to get here? It would have at least sent a message that you do get it.”

Personally, I say screw ‘em.

“FreeRADIUS is the most widely deployed RADIUS server in the world. It is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs. It is also widely used in the academic community, including eduroam. The server is fast, feature-rich, modular, and scalable.” –FreeRADIUS home page

I’ve been using FreeRADIUS in production for a few years now, mostly to support wireless users. One of the benefits of FreeRADIUS — besides being open source, of course — is the numbers of backends one can use for authentication:

“If a password is not available locally for some reason, the server can pass the authentication to another system such as LDAP, PAM, Unix (/etc/passwd), Kerberos, Active Directory, or RADIUS server via RADIUS proxying. Local programs (e.g. CGI scripts) can also be used to authenticate users via shell scripts or any other method. Perl or Python scripts can be pre-loaded into the server, which significantly lowers the cost of running such programs.”

Powerful, huh? Indeed.

For this demonstration, I’m installing a new CentOS 5.2 virtual machine on my MacBook under VMware Fusion. Installing the operating system, however, is beyond the scope of this document. Also, we’ll just be using the local system database for now — we’ll save SQL and LDAP (perhaps even Active Directory) authentication for later. After we get FreeRADIUS up and running, we’ll set up a user account and then configure a Cisco router to use RADIUS for authentication.

Let’s begin with installing FreeRADIUS by running (as root) the following command:

[root@bertram ~]# yum -y install freeradius

“yum” should have went out, grabbed the appropriates packages and dependencies, and installed them. If the end of your output looks like this, you’re all set:

Complete!
[root@bertram ~]#

Because FreeRADIUS will need to use the local system database for authentication, we need to set ‘user = root’ and ‘group = root’ in radiusd.conf. This is easy enough, just open up /etc/raddb/radiusd.conf, and change the lines that reads “user = radiusd” and “group = radiusd” to “user = root” and “group = root”, respectively. Note that this (running our daemons as root) is almost always something we want to avoid. Using other authentication backends, such as SQL or LDAP, would not require this change and would allow the FreeRADIUS service to run under the default “radiusd” unprivileged account.

Next, we need to let FreeRADIUS know about our NAS — in this case, our Cisco router. For the sake of this demonstration, our router (R1) will have IP address 192.168.1.201. We’ll also need a shared secret that the router and RADIUS server use. Let’s use the ever popular “SECRET_KEY”. Add the following to the end of /etc/raddb/clients.conf:

client 192.168.1.201 {
        secret = SECRET_KEY
        shortname = R1
        nastype = cisco
}

Then, on the FreeRADIUS side, we need to create a user account in the local user database that we’ll use for actually authenticating to R1. Nothing special here, just creating a new user account and setting the password. I’ve passed the plain-text password into “passwd” via stdin so that you can see it. Normally, we wouldn’t do that — just run “passwd cisco” and enter the password when prompted:

[root@bertram ~]# /usr/sbin/useradd cisco
[root@bertram ~]# echo secret | passwd --stdin cisco
Changing password for user cisco.
passwd: all authentication tokens updated successfully.
[root@bertram ~]#

We now have a local user named “cisco” with a password of “secret” that we’ll use when it comes time to authenticate to R1. Before we can do that, however, we must let FreeRADIUS know about the user. Append the following to /etc/raddb/users:

cisco   Auth-Type := System
        Service-Type = NAS-Prompt-User,
        cisco-avpair = "shell:priv-lvl=15"

This notifies FreeRADIUS of a local user account named “cisco”. Using the “cisco-avpair” attribute in this manner allows us to automatically assign privilege level 15 to the user, removing the requirement for the user to issue “enable” (and the enable secret) in order to gain elevated access.

Let’s get started configuring R1. I’m going to assume that you’re starting from a default configuration. The first thing we want to do is create a “fallback” user account (on the router itself) that we can use to authenticate if, for some reason, connectivity to the RADIUS server is lost. Let’s create a user named “admin” with a password of “letmein”:

R1(config)#username admin privilege 15 secret letmein

Under normal circumstances, we’ll never use this local account — only when the RADIUS server is unavailable.

The first thing I need to do is configure my interface on R1 and verify we can ping the RADIUS server. Assuming you already have your router up and running, you can likely skip this step:

R1(config)#interface fastethernet 3/0
R1(config-if)#ip address 192.168.1.201 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#
*Mar  1 00:10:14.635: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar  1 00:10:15.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
R1(config-if)#do ping 192.168.1.51

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.51, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/11/24 ms
R1(config-if)#

Excellent, all set! Let’s start configuring R1 for AAA:

R1(config)#aaa new-model
R1(config)#radius-server host 192.168.1.51 auth-port 1812 acct-port 1813 key SECRET_KEY

AAA should now be enabled on R1. Note that we provided the IP address of the RADIUS server as well as the shared secret we configured in FreeRADIUS earlier. In addition, we must specify the “auth-port” and “acct-port” used by FreeRADIUS, as these are different from Cisco’s defaults (1645 and 1646). Let’s configure authentication:

R1(config)#aaa authentication login default group radius local
R1(config)#line vty 0 4
R1(config-line)#login authentication default
R1(config-line)#line con 0
R1(config-line)#login authentication default

Here, we’ve told R1 to use RADIUS for authentication and to fall back to the local user database if the RADIUS server is not available. We don’t want to DoS ourselves!

The following command will allow the user to run an “exec” shell when logging into the router:

R1(config)#aaa authorization exec default group radius if-authenticated 

Last, but not least, we want accounting (the final “A” in “AAA”):

R1(config)#aaa accounting exec default start-stop group radius
R1(config)#aaa accounting system default start-stop group radius

That should be enough to allow us to login with our local (Linux) system account “cisco” that we created earlier. Let’s give it a shot:

macbook:~ jlgaddis$ telnet 192.168.1.201
Trying 192.168.1.201...
Connected to 192.168.1.201.
Escape character is '^]'.


User Access Verification

Username: cisco
Password:

R1#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
Ethernet0/1                unassigned      YES unset  administratively down down
Ethernet0/2                unassigned      YES unset  administratively down down
Ethernet0/3                unassigned      YES unset  administratively down down
Serial1/0                  unassigned      YES unset  administratively down down
Serial1/1                  unassigned      YES unset  administratively down down
Serial1/2                  unassigned      YES unset  administratively down down
Serial1/3                  unassigned      YES unset  administratively down down
FastEthernet3/0            192.168.1.201   YES manual up                    up
R1#exit
Connection closed by foreign host.
macbook:~ jlgaddis$

Success! We’ve installed FreeRADIUS, added a local user account, set up the NAS client (R1) and configured it to authenticate against the RADIUS server. Let’s take a look at what was logged by FreeRADIUS:

[root@bertram ~]# cat /var/log/radius/radacct/192.168.1.201/detail-20081119
Wed Nov 19 00:24:47 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Status-Type = Start
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072287

Wed Nov 19 00:25:14 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Terminate-Cause = User-Request
        Acct-Session-Time = 27
        Acct-Status-Type = Stop
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072314

[root@bertram ~]#

If there’s interest, I may expand on this later to include huntgroups, multiple RADIUS servers, using MySQL for accounting, or even through some LDAP and/or Active Directory authentication into the mix. If you’re interested, please leave a comment below!

Many months have passed since then and the wireless issues have went away. Unfortunately, I don’t really remember when they went away. I’m not sure if it had anything to do with the firmware upgrade or not.

Regardless, I browsed over to the DD-WRT site again to see if there was newer firmware available. There was, so I decided to upgrade. Upgrading to the latest version was really easy:

[jlgaddis@cleveland ~]$ ssh root@ap
root@ap's password:
root@router:~# cd /tmp
root@router:/tmp# wget http://tinyurl.com/5qv69u
root@router:/tmp# write dd-wrt.v24_vpn_generic.bin linux

At this point, we have a few minutes to kill. The flash memory isn’t the fastest in the world, and it’ll take a bit to save the file to flash. Once it’s done and our prompt has came back back, we just need to reboot.

root@router:/tmp# reboot

Give the router a minute or two to reboot, and we should be able to login again:

[jlgaddis@cleveland ~]$ ssh root@ap
DD-WRT v24 vpn (c) 2008 NewMedia-NET GmbH
Release: 07/27/08 (SVN revision: 10011)
root@ap's password:
==========================================================

 ____  ___    __        ______ _____         ____  _  _
 | _ \| _ \   \ \      / /  _ \_   _| __   _|___ \| || |
 || | || ||____\ \ /\ / /| |_) || |   \ \ / / __) | || |_
 ||_| ||_||_____\ V  V / |  _ < | |    \ V / / __/|__   _|
 |___/|___/      \_/\_/  |_| \_\|_|     \_/ |_____|  |_|

                       DD-WRT v24
                   http://www.dd-wrt.com

==========================================================


BusyBox v1.11.1 (2008-07-27 16:20:53 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

root@router:~# exit
Connection to ap closed.
[jlgaddis@cleveland ~]$

I adhere to the KISS principle so to avoid adding more virtual routers to the topology to act as hosts, we’re going to use the loopback 0 interfaces on R2 and R3 that we configured last time as our end IP addresses for testing. If you missed the last lab, go ahead and get it set up and verify full connectivity between the routers and then continue on.

Okay, so we have R1, R2, and R3 up and running, EIGRP adjacencies established, and full routing between all interfaces. Let’s jump right in to setting up our IPSec VPN!

Our first step is to configure the ISAKMP policies on each router. In this lab, we’ll use a pre-shared key for authentication, 128-bit AES for our encryption algorithm, Diffie-Helman group 2 (1024-bit modulus) and SHA hashing:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#crypto isakmp policy 10
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#encryption aes 128
R2(config-isakmp)#group 2
R2(config-isakmp)#hash sha

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption aes 128
R3(config-isakmp)#group 2
R3(config-isakmp)#hash sha

Our next step is to configure the pre-shared key that we wish to use. Note that we must use the same key (”SECRET_KEY”) on both ends of the VPN:

R2(config-isakmp)#crypto isakmp key 0 SECRET_KEY address 172.16.123.3 no-xauth

R3(config-isakmp)#crypto isakmp key 0 SECRET_KEY address 172.16.123.2 no-xauth

With our ISAKMP policy and pre-shared key configured, we can now define our transform set:

R2(config)#crypto ipsec transform-set R2_R3_TRANSFORM esp-aes 128 esp-sha-hmac

R3(config)#crypto ipsec transform-set R3_R2_TRANSFORM esp-aes 128 esp-sha-hmac

Our next step will be to tell the routers what traffic should be encrypted. We do this with an access list. For this lab, we’ll tell R2 that any traffic from 172.16.2.2 destined for 172.16.3.3 should be encrypted. On R3, we’ll do just the opposite: any traffic from 172.16.3.3 destined for 172.16.2.2 should be encrypted. Note that the access lists on each end must be a “mirror image” of each other for the VPN to properly function:

R2(cfg-crypto-trans)#ip access-list extended ENCRYPTED_TRAFFIC
R2(config-ext-nacl)#permit ip host 172.16.2.2 host 172.16.3.3

R3(cfg-crypto-trans)#ip access-list extended ENCRYPTED_TRAFFIC
R3(config-ext-nacl)#permit ip host 172.16.3.3 host 172.16.2.2

Awesome, almost done! We have two steps left. We still need to configure our crypto maps and then apply them to the appropriate interfaces. Once that’s done, we should have connectivity. Let’s set up the crypto maps:

R2(config-ext-nacl)#crypto map R2_R3_MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R2(config-crypto-map)#set peer 172.16.123.3
R2(config-crypto-map)#match address ENCRYPTED_TRAFFIC
R2(config-crypto-map)#set transform-set R2_R3_TRANSFORM

R3(config-ext-nacl)#crypto map R3_R2_MAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R3(config-crypto-map)#set peer 172.16.123.2
R3(config-crypto-map)#match address ENCRYPTED_TRAFFIC
R3(config-crypto-map)#set transform-set R3_R2_TRANSFORM

Now we just apply the crypto maps to the appropriate interfaces (serial 0/0, in both cases here) and we should be good to go:

R2(config-crypto-map)#interface serial 0/0
R2(config-if)#crypto map R2_R3_MAP
R2(config-if)#
*Mar  1 00:13:02.011: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

R3(config-crypto-map)#interface serial 0/0
R3(config-if)#crypto map R3_R2_MAP
R3(config-if)#
*Mar  1 00:14:31.447: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

With everything now in place, we should be able to send a ping from 172.16.2.2 (R2’s loopback0 interface) to 172.16.3.3 (R3’s loopback0 interface) and get a response. Note that, because of our access list, we must specify 172.16.2.2 as the source IP address of the pings:

R2#ping 172.16.3.3 source 172.16.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.2 
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/71/112 ms

We can verify that the VPN is up and running with the use of “show crypto isakmp sa” and “show crypto ipsec sa”:

R2#show crypto isakmp sa
dst             src             state          conn-id slot status
172.16.123.3    172.16.123.2    QM_IDLE              1    0 ACTIVE

R2#show crypto ipsec sa

interface: Serial0/0
    Crypto map tag: R2_R3_MAP, local addr 172.16.123.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.2.2/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (172.16.3.3/255.255.255.255/0/0)
   current_peer 172.16.123.3 port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 172.16.123.2, remote crypto endpt.: 172.16.123.3
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x995FE2D0(2573198032)

     inbound esp sas:
      spi: 0x18DD060C(417138188)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: R2_R3_MAP
        sa timing: remaining key lifetime (k/sec): (4439841/3591)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x995FE2D0(2573198032)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: R2_R3_MAP
        sa timing: remaining key lifetime (k/sec): (4439841/3544)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Prior to running that ping, we could’ve done the following in Dynagen to start a packet capture:

=> capture R1 s0/0 ipsec.cap FR

We would then have ended up with a packet capture file we could load up into Wireshark. If you had done that, you would see something like this (click for larger image):

From the packet capture, we can see the ISAKMP negotiation, the IPSec negotation, as well as the ESP (encrypted) traffic between R2 and R3. Because we did the capturing on R1’s serial 0/0 interface, we actually see each packet listed twice in the capture. If we had captured at R2 or R3’s serial 0/0 interface, we would only see them once.

I hope you enjoyed the lab and learned something from it. Let me know if there’s something specific you’d like to see in future labs or video demos!

First, the physical topology:

R1 is our hub router and R2 and R3 are our spoke routers. Each router has loopback0 configured with an IP address of 172.16.x.x and each’s serial0/0 interface is configured with an IP address of 172.16.123.x, “x” being the router number (1/2/3), of course. We also throw EIGRP into the mix to get full connectivity between devices (we’ll need full connectivity for my next lab).

Dynagen .net file:

autostart = false

[localhost:7200]

     workingdir = /home/jlgaddis/dynamips/working/frame-relay

     [[3640]]
          image = /home/jlgaddis/dynamips/ios/c3640-jk9o3s-mz.123-14.T7.img
          idlepc = 0x60530abc
          ram = 128
          disk0 = 8
          disk1 = 0
          mmap = true
          ghostios = true

     [[ROUTER R1]]
          model = 3640
          console = 2000
          slot0 = NM-4T
          s0/0 = FR 1

     [[ROUTER R2]]
          model = 3640
          console = 2001
          slot0 = NM-4T
          s0/0 = FR 2

     [[ROUTER R3]]
          model = 3640
          console = 2002
          slot0 = NM-4T
          s0/0 = FR 3

     [[FRSW FR]]
          1:102 = 2:201
          1:103 = 3:301

R1 Configuration:

hostname R1
!
interface loopback 0
 ip address 172.16.1.1 255.255.255.255
!
interface serial 0/0
 encapsulation frame-relay
 no frame-relay inverse-arp
 ip address 172.16.123.1 255.255.255.0
 frame-relay map ip 172.16.123.2 102 broadcast
 frame-relay map ip 172.16.123.3 103 broadcast
 no ip split-horizon eigrp 123
 no shutdown
!
router eigrp 123
 network 172.16.1.1 0.0.0.0
 network 172.16.123.0 0.0.0.255
!

R2 Configuration:

hostname R2
!
interface loopback 0
 ip address 172.16.2.2 255.255.255.255
!
interface serial 0/0
 encapsulation frame-relay
 no frame-relay inverse-arp
 ip address 172.16.123.2 255.255.255.0
 frame-relay map ip 172.16.123.1 201 broadcast
 frame-relay map ip 172.16.123.3 201
 no shutdown
!
router eigrp 123
 network 172.16.2.2 0.0.0.0
 network 172.16.123.0 0.0.0.255
!

R3 Configuration:

hostname R3
!
interface loopback 0
 ip address 172.16.3.3 255.255.255.255
!
interface serial 0/0
 encapsulation frame-relay
 no frame-relay inverse-arp
 ip address 172.16.123.3 255.255.255.0
 frame-relay map ip 172.16.123.1 301 broadcast
 frame-relay map ip 172.16.123.2 301
 no shutdown
!
router eigrp 123
 network 172.16.3.3 0.0.0.0
 network 172.16.123.0 0.0.0.255
!

Now that everything is up and running, let’s verify that we have full connectivity between our three routers:

R1#ping 172.16.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/23/36 ms
R1#ping 172.16.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/20 ms
R1#show ip route eigrp
     172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
D       172.16.3.3/32 [90/2297856] via 172.16.123.3, 00:01:17, Serial0/0
D       172.16.2.2/32 [90/2297856] via 172.16.123.2, 00:01:17, Serial0/0

R2#ping 172.16.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/30/48 ms
R2#ping 172.16.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/29/44 ms

R3#ping 172.16.2.2 source 172.16.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/31/40 ms

Success! We have full connectivity across our frame relay network. My next lab will be covering how to set up an IPSec site-to-site VPN between R2 and R3 to encrypt our data in transit.

Remembering this list of commands is made easier by the acronym “HELL BID SC”:

• hostname
• enable secret
• line con 0
• line vty 0 4
• banner motd
• interfaces and descriptions
• show running-config
• copy run start

“We just launched a new alias for reporting certification security issues. It’s security-tipline@external.cisco.com.”

“Please use this for submitting any issues of exam theft or cheating.”

–cris cohen, from a post on linkedin.