Skip to content

Lab 1: RADIUS Authentication

Configure your Cisco router to authenticate users and EXEC mode against a RADIUS server. The RADIUS server is using a security key of mYP4$$w0rd. Create two users with privilege level 2 and 15.

It is up to you on what RADIUS server to choose although I use FreeRADIUS on Ubuntu for my lab work. I will post a configuration file soon with the answers.

Answer

Router1(config)# aaa new-model
Router1(config)# radius-server host 192.168.15.15 key mYP4$$w0rd
Router1(config)# aaa authentication login default group radius local
Router1(config)# aaa authentication exec default group radius enable

A little bit of a trick here. AAA authentication doesn’t specify the user level on the local system but instead has it on the RADIUS server. You will need to have exec users setup on the RADIUS server in addition to the administrative users. If you read my RADIUS authentication tutorial this should be pretty straight forward though.

Advertisements

Time Settings on Cisco Devices using NTP

Configuring time on our personal computers and phones is a really simple task. Unfortunately, Cisco hasn’t made it very easy to configure time on their devices. Because timestamps are such an important part of network analysis having accurate and consistent time from device to device is very important.

Note: To create consistent time between devices, this tutorial assumes you have an NTP server running or have access to an NTP server on the public Internet which to sync your devices.

All Cisco devices have at least a software based system clock. Some of them have an additional clock called the system calendar (aka. hardware clock). When a system boots, the operating system references the software clock reads the system calendar and assigns itself a time based on the calendar. NTP can set both clocks.

NTP Configuration

NTP can use authentication to make sure authorized devices are accessing the server’s resources. NTP authentication is pretty straight forward:

Router1(config)# ntp authenticate
Router1(config)# ntp authentication-key 123456 md5 value
Router1(config)# ntp trusted-key 1

ntp authenticate Turns on NTP authentication
ntp authentication-key 123456 md5 value The authentication method for NTP requires a key (in this case 123456) and an associated value which is a md5 hash.
ntp trusted-key 1 This is a key which is also used for authentication for NTP. It is different from the key in the previous command.

Note: I am not sure why it requires two different keys. If you know, please comment.

The next step is to assign NTP peers so the device can pull the date and time from the server.

Router1(config)# ntp peer 1.2.3.4

1.2.3.4 is the IP address of the server. There are other arguments which can be specified such as NTP version number and authentication keys. This tutorial is only covering the basics so none of those at this time.

NTP should now be working and the software clock is synchronized. If the system has a system calendar, run the following command to automatically update the calendar’s time:

Router1(config)# ntp update-calendar

Finally, verify your association with show ntp associations. This will output any servers you are associated with. If any of the IP addresses have a * before it, you are successfully synchronized. Cisco has a good document which details the show command.

SPAN Port Configuration

SPAN is an acronym for Switched Port Analyzer. SPAN is Cisco’s name for Port Mirroring. Other companies have their own names for it but the purpose is the same. Port Mirroring copies frames to a port for a system to read. Picture it as though it is tapping a phone line. The phone call still goes through but someone else is listening in. This description makes SPAN ports sound very scary but they do provide two very useful features: traffic logging and Intrustion Detection and/or Prevention.

Complete traffic logging is probably not very useful or feasible for most organizations but capturing bits of traffic can be very useful for debugging or training purposes. For example, have you seen two network devices (ex. router and switch) communicate and have it logged in pcap format? There is a good chance this capture was completed using a SPAN port.

The way traditional SPAN works is pretty straight forward. A port is told to send a copy of the traffic when it sends and/or receives a frame to another port called a destination SPAN port. The SPAN port sends the traffic out the line expecting something to hear it.  Note SPAN traffic can be sent from one network device through other devices using an RSPAN configuration. This document does not cover RSPAN.

The actual configuration of SPAN is pretty simple.


Switch1# configure terminal
Switch1(config)# monitor session 1 source interface FastEthernet 0/1 both
Switch1(config)# monitor session 1 destination interface FastEthernet 0/2

That is all there is to configuring a basic SPAN port. Lets break this command down a bit:

monitor session 1 monitor session is the command for SPAN configuration with 1 being the session’s unique identifier.
source interface FastEthernet 0/1 Use this interface as the place to look for traffic which should be redirected. A range can be specified as well.
both Redirect tx (out) and rx (in) traffic. Specify tx if only sent information should be redirected or rx if only received traffic should be redirected.
monitor session 1 monitor session is the command for SPAN configuration with1 being the session’s unique identifier.
destination interface FastEthernet 0/2 Use this interface as where to send traffic which should be redirected. This is where your listening device is connected.

The destination port, in this case FastEthernet 0/2, doesn’t receive any traffic from the listening device. It ignores all traffic it gets from the outside and only accepts from the SPAN source port(s) and a few other places. Because of this, the listening device won’t ever make a real connection and be able to communicate with the switch.

One final idea to keep in mind, is this only works on switches. If you have a dedicated routing device, such as a 2801 router, SPAN won’t work except for on EtherSwitch modules. The internal interfaces cannot be SPAN source or destination ports.

Cisco ASA Licensing Explained

I wrote a guest post for packetpushers.net explaining ASA licensing.

If you are not familiar with Packet Pushers, they are a podcast focused on networking. Give it a listen from their website or iTunes.

Cisco IPSec Site-to-Site Configuration

Prerequisites: IPSec basics

Configuring IPSec site-to-site VPNs on a Cisco router at a basic level isn’t all that complex but it does require a few steps which can get muddied together. An IOS feature set capable of running encryption and VPN tunnels is required. In the ISR line this includes Advanced Security and up. For ISR G2 models, a universal image with a security feature set is needed.

Phase 1

ISAKMP Phase 1 needs to be configured. One Phase 1 tunnel is created per site-to-site VPN. The configuration is pretty straight forward and largely be templated for each configuration.

Router1# configure terminal
Router1(config)# crypto isakmp policy 1
Router1(config-isakmp)# authentication pre-share
Router1(config-isakmp)# hash sha
Router1(config-isakmp)# encryption aes 128
Router1(config-isakmp)# group 2
Router1(config-isakmp)# lifetime 86400
Router1(config-isakmp)# exit
Router1(config)# crypto isakmp key p4ssw0rd  address 192.168.1.2

The other side of the VPN tunnel needs to be configured with identical commands except for the last line. The address specified is the peer address or the IP the other end of the tunnel is terminated. In this example, Router2’s IP address is used. On Router2, Router1’s external IP address is used:

Router2# configure terminal
Router2(config)# crypto isakmp policy 1
Router2(config-isakmp)# authentication pre-share
Router2(config-isakmp)# hash sha
Router2(config-isakmp)# encryption aes 128
Router2(config-isakmp)# group 2
Router2(config-isakmp)# lifetime 86400
Router2(config-isakmp)# exit
Router2(config)# crypto isakmp key p4ssw0rd  address 192.168.1.1

If you are confused, here is the breakdown on what each command does:

crypto isakmp policy 1 Sets up a new ISAKMP configuration with the policy priority of 1. When an ISAKMP tunnel is brought up, it tries to find a matching configuration with the peer. It tries the configurations order based on the policy priority with 1 being the first.
authentication pre-share States the key is pre-shared and doesn’t use certificates.
hash sha Specifies SHA-1 should be the integrity algorithm used.
encryption aes 128 Sets the encryption algorithm used to protect the sessoin.
group 2 States DH group 2 (1024 bit) should be used to generate the shared secret.
lifetime 86400 How long the tunnel should stay up for in seconds.

The key must match on both systems as this is the pre-shared key which will allow the Phase 1 tunnel to be instantiated.

Phase 2

Phase 2’s configuration is a little more complex than Phase 1’s. Here is Router1’s Phase 2 configuration:

Router1# configure terminal
Router1(config)# crypto ipsec transform-set SETNAME esp-aes esp-sha
Router1(cfg-crypto-trans)# exit
Router1(config)# access-list 101 permit ip 192.168.80.0 0.0.0.255 192.168.85.0 0.0.0.255
Router1(config)# crypto map ROUTER1_ROUTER2 10 ipsec-isakmp
Router1(config-crypto-map)# set peer 192.168.1.2
Router1(config-crypto-map)# match address 101
Router1(config-crypto-map)# set transform-set SETNAME


Router2# configure terminal
Router2(config)# crypto ipsec transform-set SETNAME esp-aes esp-sha
Router2(cfg-crypto-trans)# exit
Router2(config)# access-list 101 permit ip 192.168.85.0 0.0.0.255 192.168.80.0 0.0.0.255
Router2(config)# crypto map ROUTER1_ROUTER2 10 ipsec-isakmp
Router2(config-crypto-map)# set peer 192.168.1.2
Router2(config-crypto-map)# match address 101
Router2(config-crypto-map)# set transform-set SETNAME

crypto ipsec transform-set SETNAME esp-aes esp-sha Creates a new IPSec tunnel encryption configuration named SETNAME.
access-list 101 permit ip 192.168.80.0 0.0.0.255 192.168.85.0 0.0.0.255 This access list will be used to match traffic which should be encrypted in the VPN tunnel.
crypto map ROUTER1_ROUTER2 10 ipsec-isakmp Creates a new crypto map named ROUTER1_ROUTER2. The last argument indicates this will be an IPSec connection.
set peer 192.168.1.2 Specifies the IP of the other side of the connection.
match address 101 Associates an access-list with the crypto map. This is the rule which indicates what traffic should traverse the tunnel.
set transform-set SETNAME Associates one or more transform sets to a crypto map.

The last step in this configuration is to assign the crypto map to an interface.

Router1(config)# interface FastEthernet 0/0
Router1(config-if)# crypto map ROUTER1_ROUTER2

If debugging is turned on you will see it is now when ISAKMP is enabled. Do a similar configuration on the other side of the connection and run a ping from an internal address to an internal address on the other side. In this example, ping the 192.168.85.0 subnet from the 192.168.80.0 subnet or visa versa. Make sure routes exist on both routers for this connectivity. The first ping will fail while the VPN tunnel is established but pings after should work.

The connection can also be validated by running a show command:

Router1# show crypto engine connections active
If no entries are shown the connection isn’t established. A successful VPN connection will show three lines.

IPSec VPN Basics

At its most basic level, a VPN is supposed to encrypt data between two points. Encryption happens to be only one component of what a VPN is supposed to do. VPNs fulfill three tasks, confidentiality, integrity, and authentication, of which encryption achieves the first task.

Confidentiality

If a malicious device intercepts traffic it can glean a lot of information from it. Usernames and passwords, emails, credit card information, or anything else that can be transmitted. It is encryption’s responsibility to make the data unintelligible to anything except the sending and receiving devices.

Integrity

If an attacker intercepts traffic, the data may not only be read but edited. Algorithms create a checksum value which is verified by the receiving side. If the receiver’s data checksum matches the source’s value, the data is considered to be the same as originally sent.

Authentication

Encryption or integrity checking have no purpose if both sides of the connection cannot verify who is using it. An attacker who creates a valid VPN connection would have access to immense amounts of data. Authentication allows only approved individuals or devices to create connections.

Tunnels

IPSec is a popular type of VPN allowing both client-access and site-to-site tunnels. Before IPSec brings up an encrypted tunnel, it must authenticate both sides of the connection using IKE. In its default mode, IKE authenticates devices or users and creates the basis of the VPN session using two tunnels, also called phases.

The first tunnel is created in the IKE Phase 1 process. Phase 1 creates a secure tunnel between the devices in which the real encryption will take place. Why are two tunnels needed? Phase 1 will set configuration options which the IPSec tunnel inside will use. It will also help secure the IPSec tunnel as it is being brought up. At the basic level, VPN end-point authentication is accomplished with pre-shared keys. Hashing and encryption algorithms used in Phase 1 are set, along with timeout information.

Phase 2 is where the IPSec tunnel is configured. This is the meat and potatoes of a site-to-site configuration. Hashing and encryption algorithms are set. A few other configuration options, including which traffic should be encrypted are set. There are different methods of how to assign rules to traffic which this document will not go into. For the sake of this tutorial, assume there are rules which state what traffic should go over the VPN.

A VPN tunnel isn’t established when created. Instead, it initializes when traffic wishes to flow over it and is terminated when traffic hasn’t traversed the tunnel in a time exceeding the timeout specified in Phase 1.

In my experience, the most confusing part of a site-to-site IPSec tunnel is understanding how the encryption and hashing algorithms work together for safe communication. Expect a future post showing configuration of a VPN tunnel.

Understanding HP Networking 802.1Q Tagging

Prerequisites: CCNA level of 802.1q tagging with Cisco

HP Networking (formerly Procurve) has two networking lines. They developed their E-series (now a deprecated marketing term) in house. In April of 2010 HP bought 3com. The legacy HP equipment uses different 802.1Q tagging nomenclature from the equipment they purchased from 3Com and Cisco equipment.

There are some terminology differences between HP and Cisco which need to be clarified prior to learning about 802.1Q in the HP Networking world. When Cisco talks about a trunk, they are referring to a 802.1Q enabled link. HP Networking considers a trunk to be a port group or what Cisco calls an Etherchannel bundle. I will use the proper terms when talking about the respective vendors technologies.
When configuring Cisco VLANs, the assignment is done on the interface level. In other words, VLANs are assigned to interfaces. Legacy HP gear works the other way. Here is a comparison. In the Cisco world, VLAN assignment is done like this:

CiscoSwitch1(config)# interface FastEthernet 0/1
CiscoSwitch1(config-int)# switchport access vlan 10

HP works this way:

HPSwitch1(config)# vlan 10
HPSwitch1(config-vlan-10)# untagged 1

The next difference is brought up by the example. Notice it says untagged. HP uses tagged and untagged terminology when referring to 802.1Q port states. An untagged port is another term for Cisco’s access port. If a port is untagged on a VLAN, it means it won’t send or accept frames with a 802.1Q tag in the header. In the example, HPSwitch1 will assume all frames coming into or out of port 1 are in VLAN 10.

Tagged interfaces mean there will be 802.1Q tags involved as well as multiple VLANs. Any interface can have one untagged VLANs and multiple tagged VLANs. A frame coming into the interface without a 802.1Q tag will be considered in the untagged VLAN. If a frame comes with with a 802.1Q tag, the specified VLAN must be in the list of tagged VLANs for the interface.

An example may clear this up if it is a little confusing.

HPSwitch1(config)# vlan 10
HPSwitch1(config-vlan-10)# untagged 1
HPSwitch1(config-vlan-10)# vlan 20
HPSwitch1(config-vlan-20)# tagged 1

Port 1 is now an untagged member of VLAN 10 and a tagged member of VLAN 20.

I don’t feel one is inherently better than the other. If you find one more comfortable, go ahead and prefer that syntax. Myself, I am used to working in the Cisco world so I like that way. However, as I said, it just makes it what I’m used to, not any better.