Syslog Configuration (Mac OSX)

Here is a quick dump of the config for syslog on a OS X machine running 10.5.

*I believe that about 10.8 things changed and configuration for syslog is done in the /etc/asl.conf directory.

• First off you need to navigate to the /etc/syslog.conf file.  Do a "more" on the file and have a look at what's going on.  Here is what mine looks like:

*.err;kern.*;auth.notice;authpriv,remoteauth,install.none;mail.crit      /dev/console
*.notice;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit      /var/log/system.log

# Send messages normally sent to the console also to the serial port.
# To stop messages from being sent out the serial port, comment out this line.
#*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit            /dev/tty.serial

# The authpriv log file should be restricted access; these
# messages shouldn't go to terminals or publically-readable
# files.
auth.info;authpriv.*;remoteauth.crit                    /var/log/secure.log

lpr.info                                                 /var/log/lpr.log
mail.*                                                   /var/log/mail.log
ftp.*                                                      /var/log/ftp.log
install.*                                                 /var/log/install.log
install.*                                               @127.0.0.1:32376
local0.*                                                 /var/log/airport.log
local1.*                                                 /var/log/ipfw.log
local2.*                                                 /var/log/airport.log
local3.*                                                 /var/log/airport.log
local4.*                                                 /var/log/airport.log
local5.*                                                 /var/log/airport.log
local6.*                                                 /var/log/airport.log
local7.*                                                 /var/log/router.log
*.emerg                                                  *

The most important part of all this is that the files referenced exist in the directory you outline and you have given them the correct permissions.  The ones that I have defined are the airport.log and the router.log.  The original intention was to have the wireless key rotations and user auth and associations be logged to the airport log file.  What has happened lately is that the Meraki FW's have decided to dump their flow reports there.  This is a result of a configuration setting that can be adjusted (Local0 seems to be the default) by going to the dashboard and under Alerts & Administration select the appropriate "role".  You can log Flows, URL's, Appliance Events and even IPS alerts.

Link to the documentation on this:
https://docs.meraki.com/display/MR/Syslog

IPv6 with Hurricane Electric

Configuring IPv6 

Cisco router with Hurricane Electric's tunnel service

To get this working you will need a few things:

- A publicly routable IPv4 Address
- Cisco Router running a version of IOS that will take IPv6 commands
- Account with Hurricane Electric
- Lots of patience

• Lets get started

- Hurricane is really good about giving you a sample config for the device you have complete with the tunnel interface information and IP addressing.  What they are not good at is giving you instructions on how to get your LAN setup to connect to the IPv6 cloud.  You would be left to wonder why hosts are unable to connect, if you should be setting up NAT... well wonder no more.

• Address information for the WAN
The address information you get to connect your router to the HE Router will look something like this:

Server IPv4 Address
- This is their routers internet facing IPv4 address
72.52.X.X

Server IPv6 Address
-  This is their routers internet facing IPv6 address
2001:470:1f04:XXX::2/64

-----------------------------------------------------------------------

Client IPv4 Address
- This is the IPv4 address you will put on your tunnel interface**

76.20.X.X

Client IPv6 Address
- This is the IPv6 address you will put on your tunnel interface**

2001:470:1f04:XXX::2/64

** The config that they give you has all this configured.

It looks like this:
!
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 enable
ipv6 address 2001:470:1f04:XXX::2/64
tunnel source 76.20.X.X
tunnel destination 72.52.X.X
tunnel mode ipv6ip

• Routing traffic 

Now that you have a tunnel interface you need to ensure that any traffic that comes from inside gets routed out the tunnel.  Thats where this statement comes in:

ipv6 route ::/0 Tunnel0

• Address information for the LAN
All the WAN stuff makes sense, you are connecting two tunnels with IPv4 and IPv6 addresses and setting a router.  Now what about hosts on the LAN?

- The address information that HE gives you also includes an IPv6 block that needs to be assigned to your inside network.  They call it the "Routed IPv6 Prefixes" but it really means IPv6 LAN addresses that need to be placed on your inside network.

My network has a single LAN segment so I picked used the entire /64 (which is a bazillion addresses but who cares).  If you have more that one LAN segment you can have fun with an IPv6 subnet calculator and slice the block up.

Routed /64:
2001:470:1f05:XXX::/64

• DNS Information 

You inside VLAN(s) should look something like this:
!
interface Vlan1
description LAN
ip address 192.168.X.X 255.255.255.0
ip nat inside
ip virtual-reassembly
ipv6 address 2001:470:1F05:XXX::1/64

- DHCP config for the inside VLAN looks no different for IPv6:
!
ip dhcp pool Inside
network 192.168.X.X 255.255.255.0
default-router 192.168.X.X
domain-name x.com
dns-server 208.67.222.222 208.67.220.220 (open DNS) ** you can also use 8.8.8.8
lease infinite

• OS

I have not tested with anything other than Mac OS 10.7 and 10.8 so I don't know how other operating systems acquire their IPv6 address.  This is what the ifconfig output on a host looks like:
!
inet6 2001:470:1f05:XXX:xxx:xxxx:xxxx:xxxx prefixlen 64 autoconf

If you want to see who else on your local subnet has an IPV6 address you can't do an arp -a like you would with IPV4.  You need to do a  ndp -a to see them.

• Validation 

OK, we have a Tunnel interface and we have an IPv6 address block assigned to the LAN, how do we know any traffic is getting to the IPv6 cloud?

- Ping (ping6) is your best friend for ensuring you can get to an IPv6 host.  Lets use google, or ipv6.google.com

ping6 ipv6.google.com

PING6(56=40+8+8 bytes) 2001:470:1f05:XXX:xxx:xxxx:xxxx:xxxx --> 2607:f8b0:400e:c02::68
16 bytes from 2607:f8b0:400e:c02::68, icmp_seq=0 hlim=54 time=43.195 ms
16 bytes from 2607:f8b0:400e:c02::68, icmp_seq=1 hlim=54 time=41.067 ms
!
--- ipv6.l.google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 41.067/42.131/43.195 ms

- Traceroute (traceroute6)
If pings are working great, if not, lets ensure that traffic is going out the tunnel interface.

traceroute6 ipv6.google.com
traceroute6 to ipv6.l.google.com from 2001:470:1f05:XXX:xxx:xxxx:xxxx:xxxx

30 hops max, 12 byte packets

1  2001:470:1f05:XXX::1  1.571 ms  1.036 ms  1.495 ms
2  X.tunnel.tserv3.fmt2.ipv6.he.net  27.442 ms  21.487 ms  19.709 ms
3  gige-g5-19.core1.fmt2.he.net  16.116 ms  17.895 ms  16.826 ms
4  10gigabitethernet1-1.core1.sjc2.he.net  17.334 ms  20.602 ms  39.567 ms
5  2001:4860:1:1::1b1b:0:9  16.703 ms  21.06 ms  100.722 ms
6  2001:4860::1:0:7ea  35.26 ms  32.691 ms  32.399 ms
7  2001:4860::8:0:2cb7  28.861 ms 2001:4860::8:0:2cb6  18.845 ms 2001:4860::8:0:2cb7  19.177 ms
!!
!

- ARP
Since the router has no concept of this command you need to enter the show ipv6 neighbors instead:


#show ipv6 neighbors

IPv6 Address                                            Age       Link-layer              Addr       State Interface
FE80::216:CBFF:xxxx:xxxx                    0      0016.cba3.ace0       STALE   Vl1
FE80::7ED1:C3FF:xxxx:xxxx                 101    7cd1.c399.b86c      STALE    Vl1
2001:470:1F05:xxx:xxx:xxxx:xxxx:xxxx       0 0016.cba3.ace0   STALE    Vl1
FE80::1AE7:F4FF:xxxx:xxxx                 121    18e7.f445.b82a       STALE    Vl1

!

• Links

Good support page on IPV6 and NDP discovery -  Cisco Support 

At this point you should be able to surf the expansive IPv6 Internet... kidding. You should be able to validate that your browser is not only capable but that you are able to "see" an IPv6 delivered web page.  Here is a good site to do this with.

Updated ASA/IPS Configuration

I wanted to do another config guide for this considering the design of my LAN has changed and the ASA version I am running is 8.4. The old ASA/AIP config post can be found here

On the ASA:

• The inside interface is going to be used to communicate with the IPS so here is the setup:
!
interface Vlan1
nameif inside
security-level 100
allow-ssc-mgmt <-- allows you to manage the ASA from this network
ip address x.x.200.1 255.255.255.0

• For the purposes of management I have defined the IPS as three different "objects" (https, SNMP and SSH):

object network IPS-443
host x.x.x.x
!
object network IPS-SNMP
host x.x.x.x
!
object network IPS-ssh
host x.x.x.x

• I also added access-lists to allow these through:
!
access-list outside_access_in extended permit tcp any object IPS-443 eq https
access-list outside_access_in extended permit udp any object IPS-SNMP eq snmp
access-list outside_access_in extended permit tcp any object IPS-ssh eq ssh
!

• Since the ASA is now on the inside of the network and the outside interface leads to my internal network I have to NAT things:
nat (outside,inside) source static any any destination static IPS-443 IPS-443
nat (outside,inside) source static any any destination static IPS-SNMP IPS-SNMP
nat (outside,inside) source static any any destination static IPS-ssh IPS-ssh

• A slightly different version of the class map from the original ASA/IPS config guide, now with a match any:
!
class-map ips_class
match any
!
policy-map ips_policy
class ips_class
ips inline fail-open
!
service-policy ips_policy interface outside

• Now what I thought was missing from the last post was the configuration from the IPS, so here it is:

service host
network-settings
host-ip x.x.200.2/24,x.x.200.1 < --- thats the ASA's inside network
access-list 0.0.0.0/0
!
ntp-server x.x.100.1 <-- router on the LAN acting as NTP server
summertime-option recurring
summertime-zone-name GMT-08:00
!
auto-upgrade
cisco-server enabled
schedule-option calendar-schedule
times-of-day 14:09:33
days-of-week sunday
days-of-week monday
days-of-week tuesday
days-of-week wednesday
days-of-week thursday
days-of-week friday
days-of-week saturday
!
service ssh-known-hosts
rsa1-keys x.x.x.x
length 2048
!
service web-server
!
service analysis-engine
virtual-sensor vs0
physical-interface GigabitEthernet0/0 <-- this is an ASA 5505 so this is not a physical interface.

I hope that helps. I'll include a new drawing to illustrate this at some point.

Router Recovery

This update is intended to show how to recover a router after it has choked on a software image and is now stuck in an rommon state.

• Enabling tftp service on your server/laptop
Sometimes you need to start (or maybe even kill) the tftp service on your laptop and the commands below will do the trick:

sudo launchctl load -F /System/Library/LaunchDaemons/tftp.plist
sudo launchctl unload /System/Library/LaunchDaemons/tftp.plist

• Download fresh image
Once the tftp service is enabled you need to go get yourself an image from cisco.com. Be warned, the image you want may not be the image your router can run. The reason the router choked on the image may have to do with the amount of available memory so be sure to look at the requirements before you pull one off the cisco shelf.

• Placing of image
Maybe not needed but I'll mention it anyway. Images (and anything you want to push or pull via tftp) go into the /private/tftpboot directory. You'll need to move the file after download with something like this:

system:Downloads user$ mv c2600-io3-mz.122-26c.bin /private/tftpboot/

- After this you'll need to change the permissions on the file so it can be accessed:

cd /private/tftpboot/
system:tftpboot user$ sudo chmod 777 c2600-io3-mz.122-26c.bin

• Router configuration

- All you need to do is enter a static IP (example uses 192.168.1.10) on your system and connect an ethernet cable to the router and issue the commands listed below (giving the router a 192.168.1.5 address):

rommon 1 > IP_ADDRESS=192.168.1.5
rommon 2 > IP_SUBNET_MASK=255.255.255.0
rommon 3 > DEFAULT_GATEWAY=192.168.1.1
rommon 4 > TFTP_SERVER=192.168.1.10
rommon 5 > TFTP_FILE=c2600-io3-mz.122-26c.bin
rommon 6 > tftpdnld

IP_ADDRESS: 192.168.1.5
IP_SUBNET_MASK: 255.255.255.0
DEFAULT_GATEWAY: 192.168.1.1
TFTP_SERVER: 192.168.1.10
TFTP_FILE: c2600-io3-mz.122-26c.bin

- Now the router wants to make sure you know your about the summon the RMA demons if this dosn't go well. They scare you with this message:

Invoke this command for disaster recovery only.
WARNING: all existing data in all partitions on flash will be lost!
Do you wish to continue? y/n: [n]: y

- Now the routers receives the image from your system via tftp:
.
Receiving c2600-io3-mz.122-26c.bin from 192.168.1.10 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (lots of these)

- All good and now for some cleanup:

File reception completed.
Copying file c2600-io3-mz.122-26c.bin to flash.
Erasing flash at 0x60fc0000
program flash location 0x60580000

All you need to do now is reload and say a small prayer.
rommon 7 > reload

As always,good luck!

SSH Key based authentication

It seems like I'm always connecting to servers via ssh and I hate having to remember my password. I remember a long time ago someone showed me how to place your public key on the server so you could log in automatically but then I forgot how to do it. Well thats what this BLOG is for - here are the steps to doing it.

• Generate the Keys
• Copy your public key to the server and visa versa
• Connect and authorize

• Generate the Keys
All you need to do this is enter ssh-keygen into the terminal and you will be taken through a few steps.

#1 It will ask you where you want to save it. The default is in /Users/yourname/.ssh/id_rsa. Just stick with that.

#2 It will ask if you would like to add a passphrase to the key or leave it empty - enter a password that you can easily remember - you will need to enter the password twice. After you enter the passphrase it will display the key's randomart image.

• Copy your public key to the server
Now that the keys have been created you need to move the public one to the server. Navigate to the ~/.ssh directory and inside there you will find something like this:

-rw------- 1 user staff 1743 Jan 21 21:09 id_rsa
-rw-r--r-- 1 root staff 416 Jan 21 21:09 id_rsa.pub
-rw-r--r-- 1 user staff 4252 Jan 11 22:19 known_hosts

The file you want is the id_rsa.pub file so go ahead and do a "more" on that and copy the contents to the clipboard. Now go to the server you want to add this to and log in FOR THE LAST TIME (HA!) and navigate to the ~/.ssh and touch a file and name it "authorized_keys". Then do a chmod 644 ~/.ssh/authorized_keys. After thats complete do a sudo pico authorized_keys and paste in the key info you copied to your clipboard.

• Copy your server key to you:
Same process, go to the server and do this:
1. ssh-keygen - save it to the defaut location, enter a password
2. create the authorized_keys file, chmod 644
3. pico and paste the key from YOUR machine's id_rsa.pub file

Now you have the key from the server in your authorized_keys file and the server has your key in it's authorized_keys.

• Connect and authorize
Now that the key is in both places all you need to do is log out and log back in. Once you connect from your machine to the server you will see a pop up window (in the OS, not in the terminal) that asks you to authorize the connection with your public key (the password that you entered in when you created the key) and once you do this you will have completed the handshake and never again will you need to enter a password for this server.

It's just that easy! Enjoy.

ASA 5505 AIP Module Configuration

This post is related to my experience getting the security services module or ASA-SSC-AIP-5 as it is known configured and doing something useful. We are going to cover the following things in this post:

• Getting into the module
• Configuring an IP
• Applying a license
• Setting up a schedule for it to download updated signatures
• Telling the ASA to pass the IPS traffic so it can do something useful
• Backing up the configuration
• Monitoring what the IPS is doing
• Resetting the module or formatting it
• Creating a Service Account

_________________________________________________________

• Getting into the module
First you need to SSH to the ASA and then do a show module to see the status of the IPS. It should look something like this:

!
asa# show mod

Mod Card Type Model Serial No.
--- -------------------------------------------- ------------------ -----------
0 ASA 5505 Adaptive Security Appliance ASA5505
1 ASA 5500 Series AIP Security Services Card-5 ASA-SSC-AIP-5

!
Mod SSC Application Name Status SSC Application Version
--- ------------------------------ ---------------- --------------------------
1 IPS Up 6.2(2)E4

In order to do anything beyond looking at the status of the module you will need to get into the ASDM and run through the initial configuration for the IPS.

• Configuring an IP
The configuration assistant will ask you to name the device and to select the network that you want the IPS on. In this case we have it on the inside 192.168.X.0/24 network and have assigned it a .167 address. The username and password are also needed and thats about it. Once you have this completed you can select the Intrusion Prevention tab next to the Firewall Dashboard on the home screen of the ASDM or you can open an https connection to the IP of you gave to the IPS and using Cisco IDM manage the IPS.

• Applying a license
Under configuration you can select the IPS module tab and then scroll down till you licensing. The file that you were given can be uploaded to the module by defining the local path from the update license field.

• Setting up a schedule for it to download updated signatures

In the ASDM you have an easy signature retrieval setup section, the only trouble is that if you leave it set to the default hourly boundary (like 02:00 am) it will error out with something like this: http error response: 500 error

The reason has to do with the time so it's easy enough to set it to something else (like 02:01 am) and it will work fine. Here is a link to the page that describes the fix.

• Telling the ASA to pass the IPS traffic so it can do something useful

The basic setup I have is to send traffic to the Sensor for inspection and if the module fails go around it rather than stop processing. Here is what it looks like on the ASA:

!
class-map ips_class
match access-list IPS
!
policy-map ips_policy
class ips_class
ips inline fail-open <---- important for uptime
! service-policy ips_policy interface outside
! access-list IPS extended permit ip any any
!

• Backing up the configuration

First you need to go into your server (configuration destination accepting ssh connections) and create the config file you are goign to copy over - something like asa-ips.cfg. Now do a chmod 777 and then go to the ASA (or more specifically the IPS module) and then issue this command:

IPS# copy current-config scp://serveripaddress/path/filename-ips.cfg
Password: ******
Generating current config: ..........

It should fail saying something like this:
!
Protocol major versions differ: 1 vs. 2
Unsupported remote protocol version for host, 192.168.X.X - must support SSH version 1

I tried many ways to get the configuration off the box (even changing the SSH version on the server to support v1, which eventually worked). The reason for this error message is that the server I was sending the file to was not known by the sensor. In order to correct this you need to perform the following:

IPS# ssh host-key 192.168.x.x
!

It comes back with a message about the key it's pulled back from the server. You say yes to this. If you now do a "show host-keys" or a "show host-keys 192.168.x.x" you will see that the sensor has pulled in the key for the server and will now pass it's configuration file to it.

Now try the command and after what seems like a century it will produce the config file and pass it to the server. If you have any questions about this process you can look at this link.


I'm sure why this is but I was able to alter the configuration on the server (vi /etc/sshd_config and under #Port 22 change it to "Protocol 1") and reload it. Now you should be able to issue the scp command and succeed in backing up the config.


• Monitoring what the Sensor is doing

In order to verify that the Sensor is in fact "seeing" traffic and acting on it you can enable signatures 2000 and 2004. These are for ICMP messages (pings) and once enabled you should be able to see them trigger by pinging something behind the IPS.

• Resetting the module or formatting it

From the ASA you can reload or reset the module with the following command:


asa# hw-module module 1 ?

  allow-ip              Allow specific hosts/network to access the module
  ip                        Configure management IP parameters
  password-reset    Reset the CLI password on the module
  recover                Configure recovery of this module
  reload                  Reload the module
  reset                    Reset the module
  shutdown            Shut down the module

• Creating a Service Account
This link has some great info on how to create a services account on the IPS so you can do all kinds of cool unix commands. I created an account in an attempt to get tftp to work but I ended up altering the server to support SSH V1 instead:

http://flylib.com/books/en/2.464.1.133/1/

Web Filtering with Regular Expressions

I posted something similar to this a while back but the intent of that post was to show how you could specify certain URL's and then drop everything else. That is sort of an odd setup so I thought I would try and document something a little more common.

• In this design we are turning on http inspection and then calling out a few web sites with regular expressions and then based on a match dropping that connection - simple. Because class-maps and policy-maps match statement are so nested and a little confusing to decipher I have laid out exactly what is being done to make all this work.

• Step 1 - The first thing we are doing is defining the regular expressions. You give them a name and you add in the FQDN


• Step 2 - The next step is to create a regular expression class map called blacklist and add in a match statement that points back at the regular expressions you defined a step ago. If later on you decide to add more sites to this "forbidden list" then you would create them as you did in step 1 and then add then under the class map you just created here in step 2.

• Step 3 - Now we're ready to enter some intelligence into this setup. The key to this step is the "match request header" portion. This tells the ASA that you want to match the http header with the regular expressions you defined - they're referenced as class "blacklist" from step 2.


• Step 4 - Here we create a policy-map called black-regex. This is simply the action you want to take after all the criteria are met. In this case it's drop-connection.


• Step 5 - Now we define the global policy (if one does not already exist on the ASA) and the statement class inspection_default will get you a bunch of other inspections that you may or may not want - the one we care about is defined as inspect http and then we reference black-regex.


• Step 6 - This is the most important step in the process. Here we put all of this into action by allying it on an interface. Since we are attempting to stop people from the inside from going to these sites we apply it there.

This could be seen as the poor network engineers web filter or a way to kill youtube the next time a celebrity dies and the entire office decides to suck up every last bit of available bandwidth...

Here are the commands in the illustration laid out for you to copy:


regex forbid1 "xxy.com"
regex forbid2 "xxy.com"
!
class-map type regex match-any BLACKLIST
match regex forbid1
match regex forbid2
!
class-map type inspect http match-all BLACKMAP
match request header host regex class BLACKLIST
!
policy-map type inspect http BLACK-REGEX
parameters
class BLACKMAP
drop-connection
!
policy-map global_policy
class inspection_default
inspect http BLACK-REGEX
!
service-policy global_policy [interface or global]

Happy filtering!

basic commands for snmpwalk

The concept of snmpwalk is very simple. All you are doing is asking a remote device that has an snmp string configured about a particular MIB. In the case of this example I am asking an IPS about it's operational status and it's interfaces. As long as you are allowed access to request the information (in the case of the IPS I specifically allowed the workstation I am requesting the information from) you should have no problem.

• From a unix box you would issue the following:

snmpwalk [the version of snmp it's running]
-c [the snmp sting you configured for read only access]
[the ip address of the remote device]
[the information being requested] You can get a listing of supported MIB's here

• It ends up looking something like this:

host$ snmpwalk -v2c -c public x.x.x.x ifOperStatus

- This is the output that you get for the operational status request:
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: up(1)
IF-MIB::ifOperStatus.5 = INTEGER: down(2)

• Same thing for an interface description request:

host$ snmpwalk -v2c -c public x.x.x.x ifDescr
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: eth0
IF-MIB::ifDescr.3 = STRING: sy0_0
IF-MIB::ifDescr.4 = STRING: ma0_0
IF-MIB::ifDescr.5 = STRING: ge0_0

• And another output from the interface admin status

host$ snmpwalk -v2c -c public x.x.x.x ifAdminStatus
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: up(1)
IF-MIB::ifAdminStatus.5 = INTEGER: down(2)

Happy querying!

Upgrading ASA 5505 Memory and Flash

This post is focusing on the upgrade process for the ASA 5505 from version 8.2 to 8.3. The new code requires more memory and so you will need to crack the box open and pull out the existing memory module and if you want, the compact flash module as well.

The process is very easy, just flip it over and pop the tree screws loose (pull the sides apart and lift up and the cover should come right off). The next step is to pull the memory module out and replace it - super easy and you can watch someone do it on youtube here.

Now comes the hard part - upgrading the compact flash. You would think you could pull the existing flash card out of the slot (the one that the cover was obscuring) and place the new one in the slot, power it up and dump into RMON and erase it - like this:.


rommon #1> erase ?

Erase storage media, valid for this platform:
disk0: - erase this device
all - erase all devices listed above

!
rommon #1> erase disk0:

About to erase the selected device, this will erase
all files including configuration, and images.
Continue with erase? y/n [n]: y

Erasing Disk0:
.................................................

Then all you would need to do is connect the old compact flash card to a USB reader and pull the files off the old one (remember to get the hidden directories) and then copy those onto the new card....

• Nope. The card once formatted by the ASA is unreadable in a PC. The format that is required is Microsoft FAT 16.

Going back to the PC and the unreadable flash card - format the card to the correct type and then copy over the files and clean things up a bit. It should look something like this when you list all the files from a PC:


drwxrwxrwx 816 Nov 24 22:56 .
drwxr-xr-x 136 Nov 24 22:56 ..
!
<---- .private is where all the magic files are stored

drwxrwxrwx 408 May 6 2008 .private
!
-rwxrwxrwx 15962112 Nov 20 2010 asa832-k8.bin
-rwxrwxrwx 16275456 May 11 2009 asa821-k8.bin
!
-rwxrwxrwx 14503836 Nov 20 2010 asdm-634.bin
-rwxrwxrwx 11348300 May 11 2009 asdm-621.bin
!
drwxrwxrwx 102 May 11 2009 coredumpinfo
drwxrwxrwx 68 May 6 2008 crypto_archive

• Now take that freshly loaded new flash card and place it into the ASA and boot it up.

Good luck!

Injecting a default route into OSPF

This post will build off the BGP Basics post that I did earlier this month. Here is what we are looking to achieve this time:

• The ISP router will advertise a default route to his neighbor R1 (acme.com's internet gateway)
• R1 will then advertise to R2 and R3 via OSPF the default route
• R2 and R3 will be able to access the 172.16.1.0/21 network even though they have no specific route to this network

Here we go:



• Starting with the ISP router, we are going to remove the default route that we added in on the last post

ISP#
!
no ip route 0.0.0.0 0.0.0.0 Null0

We still have the default-originate statement under the router bgp 64004 statement so we should be good. Over on R1 we should see that he has an entry that looks like this:

R1#
!
show ip route
!
B* 0.0.0.0/0 [20/0] via 10.10.1.2, 00:16:27

• Next we are going to look at R2 and R3 to see what routes they have. They should look something like this (taken from R2)



• On R1 we are going to add a statement to the OSPF process that will advertise the default route.

R1#
!
router ospf 1
!
default-information originate

On R2 and R3 we see this entry for the default route and we also see a gateway of last resort set (from R2):



• Now if we were to go back to the ISP router and pull the default-originate statement from BGP (or down the serial 0/0 interface) what do you think we will see on R1?

- Answer: R1 will no longer have a route to 0.0.0.0 from the ISP router. Because of this R2 and R3 have lost their default route and gateway of last resort. The reason for this is because the route will not be advertised to other OSPF neighbors unless it's in R1's table.

Now that we have established this we can restore the default route and test the theory that we can reach things from R2 and R3 that are not in their route table.

• The network 172.16.3.0 exists off the ISP router and specifically 172.16.3.1. If we ask R2 about this network is tells us it has no idea what we are talking about:

R2#show ip route 172.16.3.1
% Network not in table

When we ping it here is what we see:

R2#ping 172.16.3.1
!
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/30/44 ms

A traceroute shows that it gets to the ISP router just fine:

R2#traceroute 172.16.3.1
!
Tracing the route to 172.16.3.1

1 192.168.2.1 24 msec 20 msec 20 msec
2 10.10.1.2 24 msec * 20 msec
[stop]

BGP Basics

I have long admitted that I am not a BGP expert and so I will try my best get better with it over the course of the next few blogs related to configuration and redistribution.

• The example I am working with today is a very basic setup with an ISP router and three routers inside what we will call the acme.com network. The ISP router is in AS 64004 and has a default route which it will be advertising into R1 at acme. The R1 router will be running BGP AS 64001 and the two will be defined as neighbors.




Here is what is needed to make this work:

ISP#
!
router bgp 64004
neighbor 10.10.1.1 remote-as 64001

R1#
!
router bgp 64001
neighbor 10.10.1.2 remote-as 64004

• With that basic information entered in we should see the neighbors form and a "show ip bgp summary" on the ISP router will show you this:



• The next part of this is to get the networks that connect from R1 to R2 and R3 (192.168.2.0/24 and 192.168.3.0/24) advertised to the ISP router. First we need to get them into OSPF and this is what needs to be placed into R1, R2, and R3:

Rx#
!
router ospf 1
log-adjacency-changes
network [IP of the loopback interface of the router] area 0
network 192.168.0.0 0.0.3.255 area 0

This will get you adjacency between all three routers. Something like this (shown from R3's perspective):



• Now on the R1 router we add in the network statements under the BGP process for the 192.168.2.0 and 192.168.3.0 networks

R1#
!
router bgp 64001
network 192.168.2.0
network 192.168.3.0
!

The ISP router should now see the two networks:

ISP# show ip route
!
B 192.168.2.0/24 [20/0] via 10.10.1.1, 00:00:21
B 192.168.3.0/24 [20/0] via 10.10.1.1, 00:00:22

• Now lets create a default route on the ISP router (in this case to null 0)

ISP#
!
ip route 0.0.0.0 0.0.0.0 Null0

• Now lets advertise that route to our neighbor R1 at 10.10.1.1

ISP#
!
router bgp 64004
neighbor 10.10.1.1 default-originate

On the R1 router we now see the a default route learned via BGP

R1# show ip route
!
B* 0.0.0.0/0 [20/0] via 10.10.1.2, 03:07:04

• This is the final result. A very simple network design that we will continue to modify over the next few blogs:

Call Manager Express over an IPSec Tunnel

This one isn't going to be easy to explain in just text so lets looks at the picture of the network first:



This design has a bunch of technologies mixed into it so I have laid out the goals and the configuration that supports the design.

• #1 Bring up a 2811 named Chico running Advanced IP Services 12.4(15) T9 and hang a WAN connection off it - using either a static IP, or DHCP given address, both option will be shown.

11 -rw- 51432612 May 22 2009 07:17:46 -07:00 c2800nm-advipservicesk9-mz.124-15.T9.bin

interface FastEthernet0/0
ip address 192.168.100.1 255.255.255.252
duplex auto
speed auto

• #2 Configure DHCP and option 150 on Chico to show the devices (phones) where the Call Manager Express (CME) lives.

ip dhcp pool VOICE
network 172.16.100.0 255.255.255.0
option 150 ip 162.2.245.1
default-router 172.16.100.1

ip dhcp excluded-address 172.16.100.1

• #3 Configure a PoE switch with a voice vlan for the phones to hang off and uplink that to Chico via a trunk.

chico#
interface FastEthernet0/1.2
encapsulation dot1Q 2
ip address 172.16.100.1 255.255.255.0

• #4 Build a WAN between Chico and a 2801 named Redding and load Advanced IP Services 12.4(15) T7 and the appropriate CME files into its flash.

chico#
router ospf 1
log-adjacency-changes
redistribute connected subnets
network 192.168.100.0 0.0.0.3 area 1

sacramento#
router ospf 1
log-adjacency-changes
redistribute connected subnets
network 10.10.1.4 0.0.0.3 area 0

yolo#
router ospf 1
log-adjacency-changes
redistribute connected subnets
network 10.10.1.4 0.0.0.3 area 0
network 192.168.100.0 0.0.0.3 area 1

redding#
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

- Files in Redding's Flash. Not sure all this stuff is needed but here's the mess:

1 10035 Feb 1 2010 18:06:10 -08:00 CME41-basic-readme.txt
2 0 Feb 1 2010 18:06:10 -08:00 gui
3 4802 Feb 1 2010 18:06:12 -08:00 gui/admin_user.html
4 657587 Feb 1 2010 18:06:16 -08:00 gui/admin_user.js
5 1602 Feb 1 2010 18:06:16 -08:00 gui/CiscoLogo.gif
6 716 Feb 1 2010 18:06:16 -08:00 gui/CME_GUI_README.TXT
7 953 Feb 1 2010 18:06:16 -08:00 gui/Delete.gif
8 16344 Feb 1 2010 18:06:18 -08:00 gui/dom.js
9 864 Feb 1 2010 18:06:18 -08:00 gui/downarrow.gif
10 6146 Feb 1 2010 18:06:18 -08:00 gui/ephone_admin.html
11 4658 Feb 1 2010 18:06:18 -08:00 gui/logohome.gif
12 3724 Feb 1 2010 18:06:18 -08:00 gui/normal_user.html
13 81443 Feb 1 2010 18:06:20 -08:00 gui/normal_user.js
14 1347 Feb 1 2010 18:06:20 -08:00 gui/Plus.gif
15 843 Feb 1 2010 18:06:20 -08:00 gui/sxiconad.gif
16 174 Feb 1 2010 18:06:20 -08:00 gui/Tab.gif
17 2431 Feb 1 2010 18:06:20 -08:00 gui/telephony_service.html
18 870 Feb 1 2010 18:06:20 -08:00 gui/uparrow.gif
19 9968 Feb 1 2010 18:06:22 -08:00 gui/xml-test.html
20 3412 Feb 1 2010 18:06:22 -08:00 gui/xml.template
21 496521 Feb 1 2010 18:06:26 -08:00 music-on-hold.au
22 0 Feb 1 2010 18:06:26 -08:00 phone
23 0 Feb 1 2010 18:06:26 -08:00 phone/7906-7911
24 0 Feb 1 2010 18:07:08 -08:00 phone/7921
25 0 Feb 1 2010 18:08:18 -08:00 phone/7936
26 0 Feb 1 2010 18:08:32 -08:00 phone/7940-7960
27 0 Feb 1 2010 18:08:42 -08:00 phone/7941-7961
28 42944292 Feb 3 2010 15:43:44 -08:00 c2801-advipservicesk9-mz.124-15.T7.bin
29 2453223 Feb 1 2010 19:10:24 -08:00 apps41.8-2-2ES1.sbn
30 435144 Feb 1 2010 19:10:26 -08:00 cnu41.8-2-2ES1.sbn
31 2141085 Feb 1 2010 19:10:42 -08:00 cvm41sccp.8-2-2ES1.sbn
32 509001 Feb 1 2010 19:10:46 -08:00 dsp41.8-2-2ES1.sbn
33 229364 Feb 1 2010 19:10:48 -08:00 jar41sccp.8-2-2ES1.sbn
34 642 Feb 1 2010 19:10:48 -08:00 SCCP41.8-2-2SR1S.loads
35 642 Feb 1 2010 19:10:48 -08:00 term41.default.loads
36 642 Feb 1 2010 19:10:48 -08:00 term61.default.loads
37 129828 Feb 1 2010 21:23:42 -08:00 P00308000400.bin

• #5 Building the ephones and telephony-service on Redding

To get to the CME GUI on the router you need to set this path:
!
ip http path flash:/gui

As you can see from the flash directory listing above the /gui is where all the files that make the CME web function.

This is a dump of all the files you find in the flash after performing the steps outlines in the "archive" retrieval. That process is documented here:

1. Download the phone load files from CCO. The latest load files will be included in cme-124-15T.zip file or the cme-basic-4.1.0.0.tar file.

For example, if the system is running CME 4.1, you would use cme-basic-4.1.0.0.tar

All cme-basic-x.x.x.x.tar files are posted on the CCO site below:
http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp

2. Extract phone load files to your router flash. Copy the cme-basic-x.x.x.x.tar to a TFTP server,
and enter archive command to extract contents of tar file to router Flash:

For example, if you the TFTP server address is 192.168.1.1, you would enter:
archive tar /xtract tftp://192.168.1.1/cme-basic-4.1.0.0.tar flash:

3. Share the phone load files by issuing the command 'tftp-server flash:Pxxxxxx' for each file on the flash.

TFTP Server statements needed for 7941 7961 phones

archive tar /xtract tftp://x.x.x.x/cmterm-7941_7961-sccp.8-2-2SR1.tar flash:


tftp-server flash:apps41.8-2-2ES1.sbn
tftp-server flash:cnu41.8-2-2ES1.sbn
tftp-server flash:cvm41sccp.8-2-2ES1.sbn
tftp-server flash:dsp41.8-2-2ES1.sbn
tftp-server flash:jar41sccp.8-2-2ES1.sbn
tftp-server flash:SCCP41.8-2-2SR1S.loads
tftp-server flash:term41.default.loads
tftp-server flash:term61.default.loads

telephony-service
load 7941 SCCP41.8-2-2SR1S
load 7961 SCCP41.8-2-2SR1S

____________________________________________________________

TFTP Server statements for 7940 7960 phones

archive tar /xtract tftp://x.x.x.x/P00308000400.tar flash:

tftp-server flash:P00308000400.bin
tftp-server flash:P00308000400.loads
tftp-server flash:P00308000400.sb2
tftp-server flash:P00308000400.sbn

telephony-service
load 7960-7940 P00308000400

4. Specify the load command for each phone type (refer to examples above) - afterwards, configure the command "create-cnf" underneath telephony service.

For CME 4.1, your running configuration will look like this:

telephony-service
load 7960-7940 P00308000400
max-ephones 24
max-dn 24
ip source-address 192.168.1.1 port 2000
max-conferences 12 gain -6
transfer-system full-consult
create cnf-files version-stamp Jan 01 2010 00:00:00

____________________________________________________________

After following all that, this is what mine looks like:

tftp-server flash:apps41.8-2-2ES1.sbn
tftp-server flash:cnu41.8-2-2ES1.sbn
tftp-server flash:cvm41sccp.8-2-2ES1.sbn
tftp-server flash:dsp41.8-2-2ES1.sbn
tftp-server flash:jar41sccp.8-2-2ES1.sbn
tftp-server flash:SCCP41.8-2-2SR1S.loads
tftp-server flash:term41.default.loads
tftp-server flash:term61.default.loads
!!
!
sccp local Loopback0
sccp ccm 162.2.250.250 identifier 1
sccp
!
sccp ccm group 123
associate ccm 1 priority 1
associate profile 1 register IP_7961
keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 5
!
dspfarm profile 1 transcode
associate application SCCP
shutdown
!
!
dial-peer voice 1 voip
destination-pattern 9.T
session target ipv4:10.255.253.200
incoming called-number .
dtmf-relay h245-alphanumeric
no vad
!
!
telephony-service
load 7961 P00308000400
max-ephones 24
max-dn 24
ip source-address 162.2.245.1 port 2000
time-format 24
date-format dd-mm-yy
max-conferences 8 gain -6
moh music-on-hold.au
multicast moh 239.10.16.4 port 2000
transfer-system full-consult
create cnf-files version-stamp Feb 01 2010 19:20:00
!
!
ephone-dn 1 dual-line
number 43701
label Cisco
description 43701
name Admin Desk
!
!
ephone-dn 2 dual-line
number 43702
label Cisco
description 43702
name Agent Desk
!
!
ephone-dn 12 dual-line
number 4724154
!
!
ephone 1
device-security-mode none
mac-address 001F.9E24.870E
speed-dial 1 43700 label "PAGE ALL PHONES"
paging-dn 11
type 7961
button 1o1,12
!
!
!
ephone 2
device-security-mode none
mac-address 0003.E32A.1DEA
speed-dial 1 43700 label "PAGE ALL PHONES"
paging-dn 11
type 7960
button 1o2,12


• #6 Place an ASA 5500 in transparent mode in between the last hop router named Sacramento and Redding to protect the internal network and the voice traffic coming in.

ASA Version 8.2(1)
!
firewall transparent
hostname dmz-asa
!
interface Ethernet0/0
nameif outside
security-level 0
!
interface Ethernet0/1
nameif inside
security-level 100
!
description Cisco Skinny Client Control Protocol
port-object eq 2000
access-list inside_access_in extended permit ip any any
access-list outside_access_in extended permit tcp any host CME object-group Cisco_SCCP
access-list outside_access_in extended permit udp any host CME eq isakmp
access-list outside_access_in extended permit udp any host CME eq tftp
access-list outside_access_in extended permit icmp any host CME
access-list outside_access_in extended permit icmp any host Laptop
!
ip address 162.2.245.10 255.255.255.0
icmp unreachable rate-limit 1 burst-size 1
icmp permit any inside
icmp permit any outside
!
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
!
aaa authentication enable console LOCAL
http server enable
http 162.2.245.0 255.255.255.0 inside
!

#7 Build an IPSec over GRE tunnel to allow secure communication from the phones to the call manager.

Chico Router:

crypto isakmp policy 10
authentication pre-share
!
crypto isakmp key CISCO address 162.2.245.1
!
!
crypto ipsec transform-set TRANS esp-3des esp-md5-hmac
mode transport
!

crypto ipsec profile CHICO
set transform-set TRANS

crypto map IPSEC 10 ipsec-isakmp
set peer 162.2.245.1
set transform-set TRANS
match address 101
!
interface Tunnel0
ip address 10.200.1.6 255.255.255.254
tunnel source 192.168.100.1
tunnel destination 162.2.245.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile CHICO
!

access-list 101 permit ip 172.16.100.0 0.0.0.255 host 162.2.245.1

____________________________________________________________

Redding Router:

crypto isakmp policy 10
authentication pre-share
!
crypto isakmp key CISCO address 192.168.100.1
!
!
crypto ipsec transform-set TRANS esp-3des esp-md5-hmac
mode transport

crypto ipsec profile REDDING
set transform-set TRANS

!
crypto map IPSEC 10 ipsec-isakmp
set peer 192.168.100.1
set transform-set TRANS
match address 101
!
interface Tunnel0
ip address 10.200.1.4 255.255.255.254
tunnel source 162.2.245.1
tunnel destination 192.168.100.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile REDDING
!
access-list 101 permit ip host 162.2.245.1 172.16.100.0 0.0.0.255

IP Directed Broadcasts

This is a quick one. Enabling IP Directed broadcasts to allow a server to communicate on specific ports to a subnet. This was done out of necessity and more or less not something you want to do....

• Here is what was constructed for a backup service:

First you need to create an ACL that permits the ports from the server(s) that the the hosts will be backing up to:

access-list 109 remark ** Allow backup servers to send directed broadcasts limited to a single port
!
access-list 109 permit udp host 172.16.192.111 any eq [port #]
access-list 109 permit udp host 172.16.192.112 any eq [port #]
access-list 109 permit udp host 172.16.192.113 any eq [port #]

• Next you need to make a statement on the interface (in this case it's a cat 6500 and it's the primary interface in an HSRP setup) to allows the communication through to the subnet:

interface Vlan100
description Some LAN Segment
ip address 172.16.105.11 255.255.250.0
ip helper-address [DHCP Server #1]
ip helper-address [DHCP Server #1]
no ip redirects
ip directed-broadcast 109 <----- this references the ACL 109
ip pim sparse-mode
ip cgmp
no ip mroute-cache
standby 1 ip 172.16.105.1
standby 1 priority 150
standby 1 preempt
!

• Thats all you need to do to poke a hole in a subnet and allow directed broadcasts.

MAN Link Failover

This is a quick example of the setup for failing from a 100MB connection (something like OPT-E-MAN) to a 10MB connection (not really a service but it's a slower speed link and for the purposes of this example it's easy).

This is not rocket science and EIGRP is going to do all the work but I wanted to document this more for the fact that I had never done integrated routing and bridging on a router before (bridge irb).




The setup is simple. We have a router at each end of this with a LAN segment. The Eureka side has 172.16.200.3/32 and the Sacramento side has 172.16.200.4/32. From the Eureka router we have two paths to Sacramento, one through a high speed link in blue and a slower speed link in red. The interface with the 172.16.8.1/24 address will be preferred over the 172.16.1.10 as you can see in this show eigrp topology:

sacramento#show ip eigrp topology
!
IP-EIGRP Topology Table for AS(100)/ID(172.16.200.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 172.16.200.4/32, 1 successors, FD is 128256
via Connected, Loopback1
P 172.16.200.3/32, 1 successors, FD is 156160
via 172.16.8.1 (156160/128256), FastEthernet0/1
via 172.16.1.10 (409600/128256), FastEthernet0/0

• The real heart of this configuration and the reason I am writing this is the configuration on the provider routers. The FastEthernet0/0 and FastEthernet0/1 interfaces need a "bridge-group 1" statement on each in order to group them and allow L2 traffic to pass from one provider switch to the other. The other key part of this is the "bridge 1 protocol ieee" statement and the "bridge irb" statement. Here is what it looks like from the Redding router:

redding#
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
bridge-group 1
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
bridge-group 1
!
bridge 1 protocol ieee
!
bridge irb

• Now the test. Here is the route statement on the Sacramento router for the 172.16.200.3 network:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 172.16.8.1 on FastEthernet0/1, 00:02:01 ago
Routing Descriptor Blocks:
* 172.16.8.1, from 172.16.8.1, 00:02:01 ago, via FastEthernet0/1
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1


• Now we pull the link on redding FA0/1 to the AB switch and we see the Sacramento router go through a neighbor state change:

sacramento#
04:38:10: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.8.1 (FastEthernet0/1) is down: holding time expired..

• Lets ask the Sacramento router what the route to the 172.16.200.3 network is:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 409600, type internal
Redistributing via eigrp 100
Last update from 172.16.1.10 on FastEthernet0/0, 00:00:05 ago
Routing Descriptor Blocks:
* 172.16.1.10, from 172.16.1.10, 00:00:05 ago, via FastEthernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1


• Next we restore the link on redding FA0/1 to the AB switch and we have another state change:

sacramento#
04:39:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.16.8.1 (FastEthernet0/1) is up: new adjacency

• And another check of the route shows it's back on the higher speed path:

sacramento#show ip route 172.16.200.3
!
Routing entry for 172.16.200.3/32
Known via "eigrp 100", distance 90, metric 156160, type internal
Redistributing via eigrp 100
Last update from 172.16.8.1 on FastEthernet0/1, 00:00:05 ago
Routing Descriptor Blocks:
* 172.16.8.1, from 172.16.8.1, 00:00:05 ago, via FastEthernet0/1
Route metric is 156160, traffic share count is 1
Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

• A look at the eigrp neighbors shows that the link has been up for a short time but it is preferred over the other:

sacramento#show ip eigrp neighbors
!
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
0 172.16.8.1 Fa0/1 13 00:02:15 3 200 0 18
1 172.16.1.10 Fa0/0 13 00:09:20 2 200 0 19

Router Core Dumps

I wanted to write something about a very seldom used series of commands used to save the last gasp of a router to a server via something like tftp, of in this case ftp.

• The Core dump:
How do you save a router core dump to a server?
First off you have to know that saving a core dump via the exception command - something like this...
!
router# exception dump [hostname or IP]

will pass the file via tftp to the server you defined. The issue with this is that it will only dump the first 16 MB of the core file. This is a tftp limitation so lets just move onto configuring it to use ftp.

• FTP configuration
First you have to setup the service and you would think the command would be something like "service ftp" but no...

router#ip ftp username [somename]
!
router#ip ftp password [somepassword123]

• The exception command is the next step and here are the options you get:

router#exception ?
core-file --- Set name of core dump file
crashinfo --- Crashinfo collection
data-corruption --- Data error exception handling
delay-dump --- Pause dump (in the case of dump via peer)
dump --- Set name of host to dump to
flash --- Set the device and erase permission
memory --- Memory leak debugging
protocol --- Set protocol for sending core file
region-size --- Size of region for exception-time memory pool
spurious-interrupt --- Crash after a given number of spurious interrupts

We will elect to set the protocol:
!
router#exception protocol ftp
!


• Now the real heart of al this, the dump command with the the server ip
!
router #exception dump [x.x.x.x]

Thats all their is to it. Have fun testing this one out.

Frame-Relay

Just for the record, I never liked Frame-Relay. It's old and tired and every connection should be a metro ethernet connection in my opinion.... well something better than this. But the reason I am writing this and documenting the setup of a very basic Frame-Relay connection is because it's something that is still asked about and test questions want you to be able to configure it.

Ok Here goes - We have three routers (rack1r1, rack1r2 and rack1r6) each connecting to a Frame Switch (fsw) on a different serial interface. The frame router is essentially any old router with a few serial connections and a global command "frame-relay switching" set.



• Step 1
On the fsw we setup the serial interface to rack1r1 like so:
!
frame_switch#
interface Serial1/0
description connection to r1
no ip address
encapsulation frame-relay <--- This is important
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- Need this too
frame-relay lmi-type ansi <--- another important item
frame-relay intf-type dce <--- this as well
frame-relay route 102 interface Serial1/1 201 <--- This maps traffic into fsw with DLCI 102 to rack1r2 DLCI 201
frame-relay route 103 interface Serial3/2 301 <--- This maps traffic into fsw with DLCI 103 to rack1r6 DLCI 301
!

• Step 2 and 3, you setup the interfaces that connect to rack1r2 and rack1r6. In this case it's Serial1/1 and Serial3/2:
!
frame_switch#
interface Serial1/1
description connection to r2
no ip address
encapsulation frame-relay <--- same
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- same
frame-relay lmi-type ansi <--- same
frame-relay intf-type dce <--- same
frame-relay route 201 interface Serial1/0 102 <--- ok DLCI 201 over to 102 - thats the reverse of rack1r1
frame-relay route 202 interface Serial3/2 302 <--- This is DLCI 202 over to rack1r6 which we configure below

Here is the link to rack1r6:
!
frame_switch#
interface Serial3/2
description connection to r6
no ip address
encapsulation frame-relay <---yup
keepalive 20
no fair-queue
serial restart-delay 0
clockrate 64000 <--- yea
frame-relay lmi-type ansi <--- I know...
frame-relay intf-type dce <--- I know!
frame-relay route 301 interface Serial1/0 103 <--- Reverse again 301 to 103 which is rack1r1
frame-relay route 302 interface Serial1/1 202 <--- Back to rack1r2 on 202

• OK so we have all that in place. We are ready now to configure the interfaces on the routers themselves to make all this happen:



- Starting with rack1r1:
!
rack1r1#
interface Serial0/0
description connection to frameswitch s1/0
ip address 192.168.1.1 255.255.255.248
ip pim dense-mode
encapsulation frame-relay <--- need this here also
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 102 broadcast <--- This is in place so you can ping yourself
frame-relay map ip 192.168.1.2 102 broadcast <--- map for traffic destined for rack1r2's ip
frame-relay map ip 192.168.1.3 103 broadcast <--- map for traffic destined for rack1r6's ip
frame-relay lmi-type ansi <--- the options you have here are cisco, ansi and q933a

• OK same thing on the other two routers:
!
rack1r2#
interface Serial0/0
description connection to frameswitch s1/1
ip address 192.168.1.2 255.255.255.248
ip pim dense-mode
encapsulation frame-relay <--- same thing
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 201 broadcast
frame-relay map ip 192.168.1.2 201 broadcast <--- This is in place so you can ping yourself
frame-relay map ip 192.168.1.3 202 broadcast
frame-relay lmi-type ansi <--- same
!
rack1r6#
interface Serial0/0
description connection to frameswitch s3/2
ip address 192.168.1.3 255.255.255.248
encapsulation frame-relay <--- same
keepalive 15
no fair-queue
frame-relay map ip 192.168.1.1 301 broadcast
frame-relay map ip 192.168.1.2 302 broadcast
frame-relay map ip 192.168.1.3 301 broadcast <--- This is in place so you can ping yourself

• Ok now that thats all done you should have a working model with the ability from any router to ping the other two and yourself.

Here is what the fsw should look like when you do a "show frame-relay route"

Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0 102 Serial1/1 201 active
Serial1/0 103 Serial3/2 301 active
Serial1/1 201 Serial1/0 102 active
Serial1/1 202 Serial3/2 302 active
Serial3/2 301 Serial1/0 103 active
Serial3/2 302 Serial1/1 202 active

ASA Packet Capture

This post is intended to show how to capture packets on an ASA. This is especially helpful when you are trying to determine why something is not being allowed through the FW, you can permit all traffic from a host using an ACL and then capture the traffic and find out what is going on.

• First you need to create the ACL. In this case the host 192.168.168.31 is the target and we are allowing ip to anything.
!
(config)# access-list test permit ip host 192.168.168.31 any

• Next we will define the capture for this host. We make the statement "inside" at the end because this hosts sits on the trusted inside interface.
!
(config)# capture test1 access-list test interface inside

• Now all you do is ask to see what has been captured
!
# show capture test1

• Here is a typical dump:

21 packets captured

1: 11:21:43.783315 802.1Q vlan#1 P0 192.168.168.31 > 192.168.168.221: icmp: echo reply
2: 11:22:13.784322 802.1Q vlan#1 P0 192.168.168.31 > 192.168.168.221: icmp: echo reply
3: 11:22:23.056652 802.1Q vlan#1 P0 192.168.168.31.24894 > 216.239.38.10.53: udp 60
4: 11:22:23.097559 802.1Q vlan#1 P0 192.168.168.31.50934 > 74.125.53.9.53: udp 49
5: 11:22:23.165076 802.1Q vlan#1 P0 192.168.168.31.53 > 192.168.168.221.59255: udp 281
6: 11:22:27.040464 802.1Q vlan#1 P0 192.168.168.31.43688 > 74.125.53.9.53: udp 60
7: 11:22:27.110605 802.1Q vlan#1 P0 192.168.168.31.53 > 192.168.168.221.58190: udp 498
....


• Make sure you clean up your capture when you are done so as not to add to the load of the FW unnecessarily. Here's how to stop things:
!
(config)# no capture test1

And here's how to delete the ACL:

!
(config)# no access-list test permit ip host 192.168.168.31 any

!
# show access-list test
ERROR: access-list does not exist

Have fun with this one.

ASA Regular Expression - Whitelist/Blacklist

The intent of this post is to show how you can permit specific web sites from your inside hosts and block all others. In order to do this URL (or IRI) filtering on the ASA you need to create few things.

• First off you need to decide what you want to allow by calling them out in a regex statement:
!
regex urlreg1 "cisco.com"
regex urlreg2 "yahoo.com"

• Next we will group these statements under a class-map and call it whitelist:
!
class-map type regex match-any whitelist
match regex urlreg1
match regex urlreg2

• The class-map "goodclass" just assembles the URL's that are listed in the "whitelist" and says match this.
!
class-map type inspect http match-all goodclass
match request header host regex class whitelist

• Now we need to create a class-map that blocks everything not in the allowed list. This is done by creating the "badclass" and stating "match not" for the whitelist.
!
class-map type inspect http match-all badclass
match not request header host regex class whitelist

• Here we are taking the "badclass" and "goodclass" and putting them into a policy-map that has actions. In this case the action for the "badclass" is to drop it
!
policy-map type inspect http regex-policy
parameters
class goodclass
class badclass
drop-connection

• The policy-map "global_policy" might already exist on the ASA (not sure since I have hacked mine to hell) but in any case it calls out the "class inspection_default" that has to exist on the box for the statement under the "global_policy" to take. If you are missing it here it is:

# class-map inspection_default
# match default-inspection-traffic

!
policy-map global_policy
class inspection_default
inspect http regex-policy

• This next statement applies the "global_policy" to the inside interface. Once applied this will allow users on the trusted LAN to access two sites - cisco.com and yahoo.com and thats it.
!
service-policy global_policy interface inside

Have fun with this one. Maybe call out some social networking sites in the regex statement and change the actions in the policy-map "regex-policy" to log the hits and see how often your users are accessing those sites.

Here is a graphical Illustration of what we just made:

Configuring SSL VPN on the ASA

Connections using the Cisco Anyconnect Client

The first thing to realize is that clientless SSL access is nothing more than a web page hosted by the ASA and using a self signed cert it's extremely easy to setup. What we are going to configure is much more involved...

Lets say you have a cable modem or DSL connection and you want to extend SSL VPN access to the outside world (at least those that have a valid account) you can do this by configuring your outside interface to accept connections (as well as DTLS - Datagram Transport Layer Security).



The next step is to define an address pool for this group of people coming in. In this case we have chosen a subset of the already established 192.168.168.0/24 network that is considered "inside". We have selected 192.168.168.220/30 - 192.168.168.221 and 192.168.168.222 since we only have the two free SSL licenses that came with the ASA....

Under the Configuration/ Remote Access VPN is a section labeled Network (Client) Access. Inside that you will see the address pool section. Simply create a pool and name it.



Now click on assignment policy and ensure that you have "use internal address pools" selected.





OK now we have access allowed in and a pool of addresses to give out. Lets create a group policy for these users under the Network (Client) Access. Add one called SSL_VPN_Group (if it's not already in place). Under the address pool section uncheck the inherit and select the pool we created.



Under the more options section you will need to select the SSL Client option to ensure that you are accepting connections under this policy for AnyConnect users



under the servers options you can define your own internal DNS and WINS servers (WINS... haaa). In any case an internal DNS server is useful when users connect and want to resolve internal resources.

Under the more options in this section is the domain attribute that you can pass to the clients connecting. Again, a good thing to configure.

If you want to accept traffic that is destined to just your network then in the advanced section of the policy uncheck the inherit on split tunnel policy and choose "Tunnel Network List Below". Same goes for the Network List selection - uncheck this and define the list of networks that you want to accept traffic for.

**** Tons and tons of configuration options in the policy. For now we are going to leave everything as is and take the inherit settings.


Now lets go back to AnyConnect connection profiles and select one. In this case I have used the Default RA Group and modified the settings. Make sure you remember to check the box to enable this.



Now click on edit and lets get that address pool we created and the group policy we worked so hard on connected to this profile -



Under the advanced section in client addressing ensure that you have selected the "Use Address Pool" ** This really makes little sense since we already stated in the Address Assignment Policy how we wanted to hand out addresses. Man - 10,000 options.

Also under advanced settings you can select the interface that is doing the authentication - in this case the outside interface and the local database (or a radius server).



OK.... wow that was a lot. Lets connect and get going, right? Nope. You can connect, pass the authorization get a policy and an IP assigned (even DNS and domain) but you can't route anywhere... You need to exempt the traffic from NAT. This is done under the firewall NAT rules and states that traffic sourced from anywhere destined for the SSL_VPN /30 address range is exempt.




Here are the details of the NAT policy.



That should be it. Happy connecting.

Cisco ASA Generic Access

ASA Access Rules

In order to allow generic access (web and ssh) from the outside to your internal network or DMZ you need to do one, possibly two things:

• Configure a policy to permit from a source address or range on a specific port to the network or more preferably a specific host.

• If your outside interface has a DHCP given address, then you will need to build a static NAT rule.

- Lets look at an example

1. We know that we want to allow http and ssh access from the address block 128.107.0.0 through 128.107.255.255 so we will create a network object with that /16 network and define it as "Cisco Registered"

2. We then create an access rule on the outside interface that states from that network object to "any" destination on port 80 (repeated for port 21) we want to permit it.

2a. You can optionally configure a time range for this acl to operate in. Example is 8 to 5 Monday through Friday http requests are allowed....



3. Now that you have the access permitted from a specific network into "any" device you need to pick the internal host (all having non routable IP's) and NAT the communication back out.

4. We want to have the http requests come to the web server at 192.168.1.10 so we configure a static NAT rule that says from the inside interface the source is (web server should be defined as a network object and assigned the IP 192.168.1.10) and that is translated to the outside interface using the interface IP (because we have a DHCP given IP and one exit point).

5. In the NAT rule you will want to enable PAT for the original port - 80 translated to port 80.