Skip to content

Packet-Pick-Apart for HSRP

Pre-requisites: HSRP basics

Required link: HSRP and ARP packet capture

When looking at its packets, HSRP is a relatively straight forward protocol. Each router announces its priority and come to an agreement on the active and standby routers. Every second each router sends a Hello UDP packet which declares its state. Notice the active router (192.168.10.2) sends state code 16 (active) while the standby router (192.168.10.3) sends state code 8 (standby). Alongside the state code is also each router’s priority. As long as the standby router’s priority is lower than the active router’s priority, the pattern goes on until a change occurs.

You will notice there are periodic advertisements sent out by the passive (standby) router. These announcements enable HSRP routers on the network to determine the HSRP state without being a member. These advertisements are also sent when a router is entering or leaving the passive state. Keep this in mind for later.

Packet 13

Pay attention to packet 13. The active router sends out a Hello packet with a priority of 75 instead of 100. When the standby router recognizes it has the highest priority, HSRP goes into action. First the standby router sends an advertise packet announcing it has an active interface (packet 14). Packet 15 then shows a Coup packet. Coup packets are sent when a standby router wants to become the active router. It sends its current state as well as the priority. Another advertisement packet is sent followed by a normal Hello packet, assuming it is the active router.

All this communication has happened between HSRP enables routers, blissfully ignored by downstream routers and hosts. At packet 17, no other devices are aware the HSRP active router has changed. However, the ARP tables and Spanning Tree topologies need to be updated with the path to the new active router. As far as the other devices on the network are concerned, the router was unplugged from one port and plugged into another port. The active router’s HSRP virtual MAC address (in this case 00:00:0c:07:ac:01) is broadcast in packet 18.

Packet 18

Packet 30, 31, and 32 show the HSRP topology stabilizing. The standby router goes through its Speak phase. Each time a Speak packet is sent the active router replies with a Hello packet preventing the Speaking router from becoming active. ARP packets are broadcast after 2 and 4 seconds. After the router goes from Speak to Standby, the topology is stable.

Packets 28 through 39

Packet 43 starts the process of the first router becoming active again because its tracked interface was plugged in bringing its priority back to 100. This is allowed to happen since the routers are configured with preempt, but it is not reflected in packet contents.

Debugging RADIUS Authentication with Zone-Based Firewalls

In my lab network I have a 2801 router acting as the demarc between my Linksys router (home network) and the lab network behind the 2801. All Cisco devices authenticate to a RADIUS install on a server located on my home network. In an effort to keep devices in my lab from accessing my home resources, I set up a zone-based firewall on my 2801. My home network hosts NTP, RADIUS, and TFTP services which the lab network just needs to be pingable and get SSH’d into.

I set up two zones on my router named Lab and Home. Both were assigned to zone pairs while class-maps and policy-maps were properly applied. Or so I thought. When I tried to SSH into lab devices behind the 2801, SSH would work but RADIUS authentication would hang. After analyzing my setup using show run, I decided more troubleshooting was required.

First step was to make sure RADIUS traffic was indeed being blocked by the firewall with debug policy-map type inspect detail. When RADIUS traffic passed, I saw it was indeed dropping packets to or from the standard RADIUS authentication port, 1645. The line to match RADIUS was match protocol radius. My mistake was on relying upon the router to properly detect RADIUS traffic.

RADIUS uses port 1645 for authentication. For reasons I don’t understand, Cisco devices sometimes use 1812. I looked far and wide for a list of applications zone-based firewalls detect and the properties they use for detection, but couldn’t find anything. It became apparent I wasn’t going to defeat this using their built in rules and had to define my own.

I could have created an ACL and applied it to the class-map but wanted to find a cleaner, more ZBF-like way. Cisco includes the ip port-map command which creates custom applications. I defined user-radius (note: user defined applications must begin with user-) which matches to UDP packets from port 1645 to 1646:

Router1(config)# ip port-map user-radius port udp from 1645 to 1646 description Standard RADIUS ports

In very un-Cisco like fashion, my user-radius application even showed in auto-completion when defining my matching protocol. Once the custom protocol was assigned, RADIUS authentication immediately began working.

The lesson for me is not to trust the application definition profiles provided by Cisco in zone-based firewalls.

If you know of a list of zone-based firewall application profiles, please let me know in a comment.

Lab 2: Basic Spanning Tree Topology Calculation

This topology can be seen all over study guides and for good reason as it is a basic topology which distills how STP works on its base level. Find the root switch, and label each interface as a root port, designated port, or blocking port.

Answer

This was pretty straight forward.  SW1 becomes the root bridge because it has the lowest root bridge ID (16384.0200.0000.1111). Not only is its MAC address lower, but its priority is lower as well.

Immediately both ports on the root bridge become designated ports since all ports on root bridges are designated. Default settings indicate a Fast Ethernet link has a STP cost of 19. Fa 0/2 has a SW2->SW1 cost of 19 (0 incoming, 19 added at Fa 0/2). Fa 0/1 on SW3 also has the same value because its SW3->SW1 has the same Fast Ethernet link settings back to SW1. This leaves two ports, SW2’s Fa 0/1 and SW3’s  Fa0/2 to find out which is blocking and which is designated.

STP uses four criteria to determine links:

1. Lowest root bridge ID

2. Lowest root path cost to root bridge

3. Lowest sender bridge ID

4. Lowest sender port ID

1 and 2 both are ties so we’ll have to go to the third item to break the tie. In this case, SW2 has a lower bridge ID than SW3 so SW2’s Fa0/1 becomes the designated port leaving SW3’s Fa 0/3 to go into blocking mode.

STP should now be fully converged.

VLAN Trunking Methods

Pre-requisites: VLAN basics

A network could technically have multiple VLANs using only access ports. This design isn’t all that realistic though. It is inevitable that multiple VLANs will have to traverse a single port. When a port is configured to carry multiple VLANs, it is called a trunk port.

There are two methods to allow a trunk port to carry multiple VLANs: ISL and 802.1Q. This document intends to describe both.

ISL

Inter-switch Link (ISL) is Cisco’s proprietary method for port trunking. ISL has been around for quite some time but is being phased out in favor of 802.1Q (to be discussed later). When a frame is being prepared to be sent through an ISL enabled port, ISL encapsulates the entire Ethernet frame in an ISL header and ISL CRC footer. Because information is being prepended and appended to the frame, ISL’s tagging method is sometimes called double-tagging.

 

802.1Q

801.1Q (sometimes called ‘dot one q’) is a standards based method of VLAN trunking. While ISL encapsulates the Ethernet frame, 802.1Q simply adds some information in the Ethernet header (specifically, after the source address). The 802.1Q VLAN tag is comprised of the following elements:

* 2 byte protocol ID (always 0x8100)
* 3 bit user priority (CoS)
* 1 bit canonical indicator
* 12 bit VLAN id

It is in the 12-bit VLAN id where the switch records the VLAN which this frame is assigned.

802.1Q introduces the concept of ‘native VLAN’ which isn’t present in ISL. A native VLAN is the VLAN a switch assumes the frame is a member of if there is no 802.1Q header. By default, the native VLAN is 1. However, security vulnerabilities enabled by an obvious native VLAN make changing it a recommended task.

DTP

Dynamic Trunking Protocol (DTP) is a Cisco proprietary protocol which assists in the negotiation of trunking. DTP operates in three modes:

* dynamic desirable – Actively ask neighbor to become a trunk port. This port will also become a trunk if asked by a neighbor who is also dynamic desirable.
* dynamic auto – Will go into trunk mode if it is asked by a neighbor but will not ask neighbors to become trunks.
* nonegotiate – Port permanently becomes a trunk port. These ports will not send DTP packets nor will they pay attention to any incoming DTP packets. The neighbor switch must also be set in no negotiate.

802.1Q Operation

Because ISL is a deprecated technology, I am not going to go into details about how it operates. Instead, 802.1Q’s operational basics will be explained.

Once a trunk link has been brought up and negotiated (if negotiated that is) traffic is sent over the link. Lets say the native VLAN is 2. If traffic is assigned to VLAN 2, the switch will send the frame without a 802.1Q header tag. The receiving switch, assuming it is configured properly, will know it is for VLAN 2 because there is no VLAN header. On the other hand, if a frame includes VLAN information in its Ethernet header, the switches will read the designated VLAN.

A future post will demonstrate how to configure VLAN trunking and some things to watch out for.

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.

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.

%d bloggers like this: