Tag Archives: Cisco

determining what is chewing your bandwidth

ip cef
interface dialer1
ip route-cache flow

show ip cache flow

ip flow-top-talkers
top 10
sort by bytes
cache-timeout 10000

show ip flow top-talkers

slappa#show ip flow top-talkers

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Bytes
Vi2 157.55.61.160 BV1 121.219.101.186 06 01BB CBBF 6362
BV1 121.219.101.186 Di0* 86.30.6.108 11 E644 FF29 703
Vi2 74.125.237.144 BV1 121.219.101.186 06 01BB CB37 310
Vi2 86.30.6.108 BV1 121.219.101.186 11 FF29 E644 302
BV1 121.219.101.186 Di0* 85.139.227.87 06 CBC7 60F9 280
BV1 121.219.101.186 Di0* 173.14.69.122 11 E644 C8D5 270
BV1 121.219.101.186 Di0* 85.139.227.87 11 E644 60F9 222
BV1 121.219.101.186 Di0* 85.228.99.52 11 E644 B70D 222
BV1 121.219.101.186 Di0* 178.73.26.14 11 E644 DCE1 222
BV1 121.219.101.186 Di0* 24.82.134.236 11 E644 A1BD 222
10 of 10 top talkers shown. 40 flows processed.

 

How IPSEC Works

How IPSec Works

http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=6

 

IPSec involves many component technologies and encryption methods. Yet IPSec’s operation can be broken down into five main steps. The five steps are summarized as follows:

Step 1 Interesting traffic initiates the IPSec process—Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.
Step 2 IKE phase one—IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase two.
Step 3 IKE phase two—IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.
Step 4 Data transfer—Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.
Step 5 IPSec tunnel termination—IPSec SAs terminate through deletion or by timing out.

This five-step process is shown in Figure 1-15.

Figure 1-15 The Five Steps of IPSec

Step 1: Defining Interesting Traffic

Determining what type of traffic is deemed interesting is part of formulating a security policy for use of a VPN. The policy is then implemented in the configuration interface for each particular IPSec peer. For example, in Cisco routers and PIX Firewalls, access lists are used to determine the traffic to encrypt. The access lists are assigned to a crypto policy such that permit statements indicate that the selected traffic must be encrypted, and deny statements can be used to indicate that the selected traffic must be sent unencrypted. With the Cisco Secure VPN Client, you use menu windows to select connections to be secured by IPSec. When interesting traffic is generated or transits the IPSec client, the client initiates the next step in the process, negotiating an IKE phase one exchange.

Step 1 is shown in Figure 1-16.

Figure 1-16 Defining Interesting Traffic

Step 2: IKE Phase One

The basic purpose of IKE phase one is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase one performs the following functions:

  • Authenticates and protects the identities of the IPSec peers
  • Negotiates a matching IKE SA policy between peers to protect the IKE exchange
  • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys
  • Sets up a secure tunnel to negotiate IKE phase two parameters

IKE phase one occurs in two modes:

  • Main mode
  • Aggressive mode

Main Mode

Main mode has three two-way exchanges between the initiator and receiver.

  • First exchange—The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.
  • Second exchange—This exchange uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity.
  • Third exchange—This exchange verifies the other side’s identity. The identity value is the IPSec peer’s IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bidirectional.

Aggressive Mode

In the aggressive mode, fewer exchanges are done and with fewer packets. In the first exchange, almost everything is squeezed into the proposed IKE SA values, the Diffie-Hellman public key, a nonce that the other party signs, and an identity packet, which can be used to verify the initiator’s identity through a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to sniff the wire and discover who formed the new SA. However, aggressive mode is faster than main mode.

Step 2 is shown in Figure 1-17.

Figure 1-17 IKE Phase One

Step 3: IKE Phase Two

The purpose of IKE phase two is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase two performs the following functions:

  • Negotiates IPSec SA parameters protected by an existing IKE SA
  • Establishes IPSec security associations
  • Periodically renegotiates IPSec SAs to ensure security
  • Optionally performs an additional Diffie-Hellman exchange

IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase one. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase one.

Perfect Forward Secrecy

If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

Step 4: IPSec Encrypted Tunnel

After IKE phase two is complete and quick mode has established IPSec SAs, information is exchanged by an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA. This IPSec encrypted tunnel can be seen in Figure 1-18.

Figure 1-18 IPSec Encrypted Tunnel

Step 5: Tunnel Termination

IPSec SAs terminate through deletion or by timing out. An SA can time out when a specified number of seconds have elapsed or when a specified number of bytes have passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new phase two and, if necessary, a new phase one negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire so that a given flow can continue uninterrupted. This can be seen in Figure 1-19.

Figure 1-19 Tunnel Termination

Cisco License Activation

This new system will start becoming a bother when upgrading from IP Base to another feature license. This will require the following steps:

  1. The order of a Product Authorization Key (PAK) from Cisco
  2. The Unique Device Identifier (UDI) from the Router/Switch
  3. Entered this information into the Cisco Licensing Portal
  4. Taking the information from the Portal and installing the license onto the Switch/Router

The installation of the license file can be done using the *.lic file that you receive from the Portal using the Command line interface or the Cisco License Manager software. Using the command line:

Switch#license install tftp://x.x.x.x/license.lic

Alternatively one can use the call-home feature and the PAK Number, this however would mean that you have an internet connection to the Router/Switch and you feel comfortable that you won’t have the *.lic file when things go wrong as the Switch/Router installs this directly from the License Portal:

Switch#license call-home install PAK PAK-NUMBER
CCO Username: abcdef
CCO Password:
!......................
Follow the prompts to install the license

How to pass PPTP traffic through a PIX Firewall

Cisco PIX Firewalls require two elements to pass traffic from outside (higher security) to inside (lower security): a static translation and a conduit.

For this example, assume a server has IP address 192.168.1.100 and there is an available outside address of 1.1.1.1.

First, create the static translation. This configuration line establishes a relationship between 1.1.1.1 (public Internet IP address) and 192.168.1.100 (inside, private IP address).

fixup protocol pptp 1723
static (inside,outside) 1.1.1.1 192.168.1.100 netmask 255.255.255.255 0 0

Next, create appropriate conduits to allow specific traffic to pass from the outside to the Inside interface. PPTP uses TCP/1723, and IP/47 GRE.

conduit permit tcp 1.1.1.1 eq 1723 any
conduit permit gre host 1.1.1.1 anyor
access-list 101 permit tcp any host 1.1.1.1 1723
access-list 101 permit gre any host 1.1.1.1
access-group 101 in interface outside

A couple of notes:

In the conduits and access-lists, the any keyword allows matching traffic from any IP address to pass through the firewall. This should be replaced with the source IP address of the PPTP tunnel, if at all possible.

In the access-lists, verify any existing access-lists or other traffic needed before entering the last line!

Safely Configuring Cisco Routers

Routers far away can be safely configured by using a reload command first. Before any configuration changes are made, issue a reload command to the remote router: reload in 30 or reload at 00:00 to reload at a specific time. This command instructs the router to reboot in 30 minutes. Proceed to configure the router as needed. As long as no configuration changes are saved, the router will revert to its previous configuration when it reloads. If configuration changes are successful, reload cancel will stop the pending reload. If configuration changes cause a loss of connectivity, the local side can be easily reset to the previous configuration. When the router reloads, connectivity will be restored.

Updating Cisco IOS

Following is a quick listing of the commands you need to use when upgrading the IOS firmware on your Cisco router series 1600, 2000, 2500, 3000, AS5100 and AS5200. You should consult the Cisco web site to upgrade other devices. The process involves two phases: one, set the flash to read-write and reboot; two, download the firmware and reboot. You must setup a TFTP server and make the IOS binary file available for download. If your router is not on the same network segment as your TFTP server, be sure both devices have a default route configured so that they may access one another. I recommend using a Linux box for your TFTP server, and limit access to the service with both ipchains/iptables and the tcp-wrappers hosts.allow file. The following sequence of commands can be entered via the console port, or by telnet session. I recommend you have access to the console port if something fails . . . you’ve been warned!

enable conf t config-register 0x2101 ^Z wr mem reload

The router will reboot and the flash will now be in read-write mode. This is called “boot mode.” Avoid saving anything in this mode and answer no to any prompts about saving your current configuration. If you do save your config while in this mode, it may be partially or completely erased…

enable conf t config-register 0x2102 ^Z copy tftp flash it’ll prompt for ip address… it’ll prompt for filename… use same name to save as… when asked about erase say YES to confirm… reload answer NO to save current config answer YES to continue with reload

If you pray really hard, and offer up the right sacrifices, at this point you’ll be looking at a successful router upgrade! If connecting via the console port, make sure your terminal settings are as follows:

VT100 9600 bps 8 data bits 1 stop bit no parity no flow control

Cisco VPN with NAT

Sample Config Cisco IOS VPN with NAT
1720#sh run
Building configuration…
Current configuration : 3044 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 1720
!
enable password cisco
!
username cisco password 0 cisco
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
!
no ip domain-lookup
!
ip inspect name fw http
ip inspect name fw ftp
ip inspect name fw tcp
ip inspect name fw udp
ip audit notify log
ip audit po max-events 100
!
crypto isakmp policy 3
hash md5
authentication pre-share
group 2
!
crypto isakmp client configuration group 3000client
key cisco123
pool ippool
acl 108
!
crypto ipsec transform-set myset esp-des esp-md5-hmac
!
crypto dynamic-map dynmap 10
set transform-set myset
!
!
Those two lines are missing in an older sample on Cisco’s site: VPN clients won’t connect without those
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address initiate
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
interface FastEthernet0
ip address 196.0.0.1 255.255.255.0
ip nat inside
speed auto
!
interface Serial0
ip address 193.0.0.1 255.255.255.0
ip nat outside
encapsulation ppp
no ip route-cache
no ip mroute-cache
no fair-queue
clockrate 64000
crypto map clientmap
!
ip local pool ippool 197.0.0.3 197.0.0.5
ip nat pool outsidepool 193.0.0.5 193.0.0.10 netmask 255.255.255.0
! Doesn’t work: ip nat inside source route-map nonat interface Serial0 overload
ip nat inside source list 1 interface Serial0 overload
ip route 0.0.0.0 0.0.0.0 Serial0
!
access-list 1 permit 196.0.0.0 0.0.0.255
access-list 101 permit tcp 196.0.0.0 0.0.0.255 any
access-list 101 permit icmp 196.0.0.0 0.0.0.255 any
access-list 101 permit udp 196.0.0.0 0.0.0.255 any
access-list 102 permit udp host 193.0.0.1 eq isakmp host 193.0.0.1
access-list 102 permit ahp host 193.0.0.1 host 193.0.0.1
access-list 102 permit esp host 193.0.0.1 host 193.0.0.1
access-list 102 permit udp any host 193.0.0.1 eq 62514
access-list 102 permit udp any host 193.0.0.1 eq isakmp
access-list 102 permit tcp any any
access-list 102 permit icmp any any echo-reply
access-list 108 permit ip 196.0.0.0 0.0.0.255 197.0.0.0 0.0.0.255
access-list 199 deny ip 196.0.0.0 0.0.0.255 197.0.0.0 0.0.0.255
access-list 199 permit ip 196.0.0.0 0.0.0.255 any
!
route-map nonat permit 10
match ip address 199
!
line con 0
line aux 0
line vty 0 4
login
!
no scheduler allocate
end

Start Cisco VPN before logon Windows domain

On a Windows platform, you can connect to the VPN before you log on to Windows domain.

When selecting start before logon, the VPN Client starts and displays the connection dialog box over the system logon dialog box. You connect to the VPN first and then the connection dialog box goes away. You will see the normal windows logon screen and you log on to the domain. You may also load logon script.

To activate start before logon, follow these steps:

1. Open the VPN Client Options menu and choose Windows Logon Properties.

2. Check Enable start before logon and then click OK.