Monday, September 30, 2013

Download a Packet Capture from an ASA

Firstly run your capture:
1) create an access list that will match the packets you are interested in seeing e.g:
    #access-list TESTCAP extended permit tcp host eq ldap

2) Create the capture on your ASA:
   #capture TESTCAP access-list TESTCAP interface INSIDE

Let that run then once you have collected enough data (use sh capture TESTCAP to view the capture ) transfer the capture file (pcap) to your local machine to view in a packet analyser programme such as WireShark:
1) Download and install a TFTP server programe (I used Solarwinds TFTP server) and then start the server.
2) From the firewall concerned run change to the System Context then run the following :
    #changeto context system
    #copy /pcap capture:[ContextName]/TESTCAP tftp:
    You will be asked for the destination IP - this will be your laptop IP that is running TFTP
    Note - [ContextName] should be the name of the context that the capture is running on.
3) Check the TFTP-root folder on your local machine to verify the transfer was successful.
4) Open WireShark then open the pcap file from there.

Friday, September 6, 2013

View the Pre-Shared Key on an IPsec VPN tunnel-group

When troubleshooting VPN connectivity issues a common problem is a mis-matched pre-shared key.

When you add a pre-shared key to a tunnel-group if you issue a #sh run the output hides the key with a simple *. e.g:

tunnel-group ipsec-attributes
 pre-shared-key *
 isakmp keepalive threshold 15 retry 2

To confirm precisely what has been applied (and therefore help confirm if both ends of your tunnel have the same key) use the following command:
 #more system:running-config

tunnel-group ipsec-attributes
 pre-shared-key AbCdEfG192837645
 isakmp keepalive threshold 15 retry 2

Upgrade the IOS on a Cisco Catalyst 3750 switch

Steps to conduct an upgrade of the IOS are as follows:

  1. Download the new image from using a suitable account
  2. Install a TFTP server such as SolarWinds TFTP Server (other TFTP programs are available)
  3. Boot the switch and apply an IP address to the VLAN1 interface
  4. Apply an IP in the same subnet to your PC/Laptop LAN port and cable up using a CAT5 straight through
  5. Ping both sides to confirm connectivity
  6. Copy the downloaded BIN image to the TFTP-Root folder you'll find on the C:drive
  7. Start the TFTP Server on the PC/Laptop
  8. On the switch back up the current image to your PC/Laptop #copy Flash:/[filename.bin] tftp
  9. Enter the required remote host IP and confirm the destination file name when prompted
  10. Allow the current file to copy over to the PC/Laptop
  11. Once complete delete the original from the switch to create space for the new image #delete /recursive Flash:/[filename.bin]
  12. Next copy the new image from the PC/Lpatop to the switch #copy tftp: flash:
  13. Enter the remote host details and file name then confirm
  14. Allow the file to copy
  15. Set the new BIN as the system boot image #boot system flash:/[filename.bin]
  16. write this #wr
  17. Reload

Verify the image in use via - #sh ver

It's your problem..No! it's yours!

What do you do when your firewall is receiving TCP resets from the customer yet the customer insists that they are not generating the packets from their side?

This is one that has been the focus of alot of attention this week. We could see that our VPN tunnel was being actively terminated from the customer side yet the customer stated that they weren't seeing any issues and there were no log entries on their side to suggest a problem.

In cases like these it's easy to assume that the customer is a) hiding something or b) an idiot. Thankfully after alot of consideration we settled on c) we were both right.

The cause of this issue was revealed when the customer supplied a trace route from their VPN firewall to our router on the edge of the network. Working systematically we simply ran a ping to each hop back to the customer and observed the results. The connection between us and our ISP was fine, no packet loss, and this confirmed to us that our side was good. We kept  pinging each hop in turn until Bingo! Packet Loss!

A quick search across the internet registrar websites (RIPE, AfriNIC, LACNIC, ARIN, APNIC) showed that the offending network belonged to the customers ISP. The peer between the ISP and the next hop to be precise. Once this had been established it was then easy to establish that the ISP had a case already open to investigate the peer issues and the activity we had been observing was part of it.

The result was that because packet loss was occurring, our side of the VPN kept resending tcp packets waiting for SYN ACK's that were never going to arrive (some did). The customer would get some of the resent TCP packets but because from their point of view the tunnel was up their firewall was ignoring the SYNs. Our firewall would then try again. The buffers on the customer firewall would fill up and aTCP reset would be generated because of this (note that the TCP reset was not related to the customer's active VPN Tunnel - hence they were stating that the TCP resets we were seeing were not being generated from their side of the VPN) and the process would start over again.

The morale of the story. This tale may well seem a tad dull but I have a point (really). It's about listening, it's easy to dismiss the other party as failing to listen, incompetent, inexperienced, or what have you and equally it's easy to assume that the issue is not on your network but with out thorough investigation and methodically investigating the path of the network, issues can be easily missed and assumptions be made. This in turn leads to misunderstanding and delay.

Listening. Another tool in the network engineer's toolkit.

Lesson learned...

Tuesday, September 3, 2013

VPN - QM FSM error and PFS

We're busy attempting to bring up a site to site IPSec tunnel to Cisco router from our ASA.

Phase1 is completing but Phase2 fails with a 'QM FSM Error'.

This very unhelpful error message results from PFS not matching at either end. Either set it or don't set but if you have one end configured and the other not then you'll get an error like the one above.

Check the config on both ends of your VPN and either add PFS or remove by entering the following:
[no] crypto map VPNCONNECTION set pfs [group1 | group2 | group 5 ]

  • PFS must match at either end
  • The default action on an ASA is to be off
  • If you just enter 'set pfs' and don't define a group then group1 is offered by default and group1/group2 is accepted
  • If you set the group then the same group must be returned by the remote peer.

Cisco CCDA - Done!

At the start of August I returned to the site of my last attempt and faced the Cisco CCDA once again.

This time I have re-read the OCG, read more from the Cisco Design Zone -

I had also reviewed all the exam material I had and not take the results for granted (as I did last time).

What I found with my resit was that is was SOOOOOO much harder! really hard. I'm mean difficult hard. Hard.

Cisco must have a large pool of questions on this exam as I only spotted one question on the entire exam that I recognised from my first attempt and the rest were very detailed and narrow on the topic selection. As it is, I took my time, paced my self as best I could and finished with about 5 minutes to spare. last time I done a good chunk of the exam in the first 15 minutes.

I passed with a reasonable (not brilliant) mark and I'm just grateful I'm now looking at my new certificate on the desk partition in front of me.

My advise for the exam is truely go in depth. As much as you can, learn the detail, and ensure you know the 'Key Topic' sections of OCG of by heart. It's a tough exam but lays the foundation for the ARCH exam so I guess it has to be.

I'm picking the books up in October and hope to have my CCDP by Christmas. Lets see shall we...