Cisco ASA and IOS-XE embedded packet capturing

This is a short post about a step-by-step procedure to configure packet capturing on Cisco ASA or IOS XE using the CLI.

Cisco ASA embedded packet capturing:

access-list acl_capin extended permit ip host 217.100.100.254 host 10.0.255.254
access-list acl_capin extended permit ip host 10.0.255.254 host 217.100.100.254
capture capin interface inside access-list acl_capin

or

capture capin interface inside match ip host 10.0.255.254 host 217.100.100.254
[possible in asa 8.x and later]

Show captured packets:

asa-1(config)#  show capture capin

10 packets captured

   1: 15:11:12.760092       10.0.255.254 > 217.100.100.254: icmp: echo request
   2: 15:11:12.761755       217.100.100.254 > 10.0.255.254: icmp: echo reply
   3: 15:11:12.764196       10.0.255.254 > 217.100.100.254: icmp: echo request
   4: 15:11:12.765615       217.100.100.254 > 10.0.255.254: icmp: echo reply
   5: 15:11:12.768072       10.0.255.254 > 217.100.100.254: icmp: echo request
   6: 15:11:12.769354       217.100.100.254 > 10.0.255.254: icmp: echo reply
   7: 15:11:12.771612       10.0.255.254 > 217.100.100.254: icmp: echo request
   8: 15:11:12.773077       217.100.100.254 > 10.0.255.254: icmp: echo reply
   9: 15:11:12.775548       10.0.255.254 > 217.100.100.254: icmp: echo request
  10: 15:11:12.777150       217.100.100.254 > 10.0.255.254: icmp: echo reply
10 packets shown

asa-1(config)#

asa-1(config)#  show capture capinside detail

20 packets captured

   1: 15:11:12.760092 a000.0000.0001 a000.0000.0021 0x0800 Length: 114
      10.0.255.254 > 217.100.100.254: icmp: echo request (ttl 255, id 5)
   2: 15:11:12.761755 a000.0000.0021 a000.0000.0001 0x0800 Length: 114
      217.100.100.254 > 10.0.255.254: icmp: echo reply (ttl 255, id 5)
   3: 15:11:12.764196 a000.0000.0001 a000.0000.0021 0x0800 Length: 114
      10.0.255.254 > 217.100.100.254: icmp: echo request (ttl 255, id 6)
   4: 15:11:12.765615 a000.0000.0021 a000.0000.0001 0x0800 Length: 114
      217.100.100.254 > 10.0.255.254: icmp: echo reply (ttl 255, id 6)
   5: 15:11:12.768072 a000.0000.0001 a000.0000.0021 0x0800 Length: 114
      10.0.255.254 > 217.100.100.254: icmp: echo request (ttl 255, id 7)
   6: 15:11:12.769354 a000.0000.0021 a000.0000.0001 0x0800 Length: 114
      217.100.100.254 > 10.0.255.254: icmp: echo reply (ttl 255, id 7)
   7: 15:11:12.771612 a000.0000.0001 a000.0000.0021 0x0800 Length: 114
      10.0.255.254 > 217.100.100.254: icmp: echo request (ttl 255, id 8)
   8: 15:11:12.773077 a000.0000.0021 a000.0000.0001 0x0800 Length: 114
      217.100.100.254 > 10.0.255.254: icmp: echo reply (ttl 255, id 8)
   9: 15:11:12.775548 a000.0000.0001 a000.0000.0021 0x0800 Length: 114
      10.0.255.254 > 217.100.100.254: icmp: echo request (ttl 255, id 9)
  10: 15:11:12.777150 a000.0000.0021 a000.0000.0001 0x0800 Length: 114
      217.100.100.254 > 10.0.255.254: icmp: echo reply (ttl 255, id 9)
20 packets shown

asa-1(config)#
Browser capture:
https://10.255.1.203/admin/capture/capin

Download pcap:
https://10.255.1.203/capture/capin/pcap

Disable capture and remove access-list:

no capture capin
no capture capout
clear configure access-list acl_capin
clear configure access-list acl_capout

Cisco ASR embedded packet capturing:

ip access-list extended acl_cap
 permit ip any any
 permit icmp any any
 exit
 
monitor capture mycap access-list acl_cap 
monitor capture mycap limit duration 1000
monitor capture mycap interface GigabitEthernet3 both
monitor capture mycap buffer circular size 10
monitor capture mycap start
monitor capture mycap export tftp://10.255.1.87/mycap.pcap

Show captured packets:

rtr-2#show monitor capture mycap buffer dump
0
  0000:  A0000000 0004A000 00000001 08004500   ..............E.
  0010:  00640041 0000FF01 A9530A00 FF010A00   .d.A.....S......
  0020:  FF020800 0B62000D 00000000 0000001E   .....b..........
  0030:  72BDABCD ABCDABCD ABCDABCD ABCDABCD   r...............
  0040:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0050:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0060:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0070:  ABCD                                  ..

1
  0000:  A0000000 0001A000 00000004 08004500   ..............E.
  0010:  00640041 0000FF01 A9530A00 FF020A00   .d.A.....S......
  0020:  FF010000 1362000D 00000000 0000001E   .....b..........
  0030:  72BDABCD ABCDABCD ABCDABCD ABCDABCD   r...............
  0040:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0050:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0060:  ABCDABCD ABCDABCD ABCDABCD ABCDABCD   ................
  0070:  ABCD                                  ..
...

rtr-2#show monitor capture mycap buffer
 buffer size (KB) : 10240
 buffer used (KB) : 128
 packets in buf   : 14
 packets dropped  : 0
 packets per sec  : 1
...

Disable capture and remove access-list:

monitor capture mycap stop
no monitor capture mycap
no ip access-list extended acl_cap

Ansible ASA Playbook (asa_config and asa_acl): Cisco ASA access-list

Like in my previous post in the new development version 2.2. from Ansible are new IOS and ASA core modules.

Here an example of the asa_config and asa_acl module to create and object-group in the first step and create the inside create access-list:

- name: Cisco ASA access-list config
  connection: local
  hosts: firewall
  gather_facts: false
  vars:
    cli:
      username: "{{ username }}"
      password: "{{ password }}"
      host: "{{ device_ip }}"
      authorize: yes
      auth_pass: cisco
  tasks:
    - name: create object group
      asa_config:
        lines:
          - network-object host 10.1.0.1
          - network-object host 10.1.0.2
          - network-object host 10.1.0.3
        parents: ['object-group network dummy-group']
        provider: "{{ cli }}"
#      register: result

    - name: configure access-list
      asa_acl:
        lines:
          - access-list acl_inside extended permit tcp object-group dummy-group any eq www
          - access-list acl_inside extended permit udp object-group dummy-group any eq domain
          - access-list acl_inside extended deny ip any any
        before: clear configure access-list acl_inside
        match: strict
        replace: block
        provider: "{{ cli }}" 
#      register: result

    - debug: var=result

Here output when you run the playbook the first time:

ansible-playbook cisco/asa_access-list_config.yml -i cisco/hosts

PLAY [Cisco ASA access-list config] ********************************************

TASK [create object group] *****************************************************
changed: [fw1]

TASK [configure access-list] ***************************************************
changed: [fw1]

TASK [debug] *******************************************************************
ok: [fw1] => {
    "result": "VARIABLE IS NOT DEFINED!"
}

PLAY RECAP *********************************************************************
fw1                        : ok=3    changed=2    unreachable=0    failed=0

Here the output then you run the playbook a second time, you see nothing is changed:

ansible-playbook cisco/asa_access-list_config.yml -i cisco/hosts

PLAY [Cisco ASA access-list config] ********************************************

TASK [create object group] *****************************************************
ok: [fw1]

TASK [configure access-list] ***************************************************
ok: [fw1]

TASK [debug] *******************************************************************
ok: [fw1] => {
    "result": "VARIABLE IS NOT DEFINED!"
}

PLAY RECAP *********************************************************************
fw1                        : ok=3    changed=0    unreachable=0    failed=0

Read my new post about an Ansible Playbook for Cisco ASAv Firewall Topology

Cisco ASA Failed to connect to the host: no matching key exchange method found

When you have problems connecting to your Cisco ASA and see following error message:

Cisco ASA Failed to connect to the host via ssh: Unable to negotiate with 192.168.100.204 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1\r\n”,

Workaround to change ssh diffie-hellman group:

conf t
ssh key-exchange group dh-group14-sha1
exit 
wr mem

Now you can try it again and able to connect to the ASA.

Setup Juniper ISG NSRP cluster

This post describes how to rebuild a Juniper NSRP Cluster if the first Juniper firewall is already configured for NSRP.
Please make sure you have the following prerequisite on both Firewalls.

Minimum software and hardware requirements for configuring Active / Passive NSRP:

  • Firewall’s with identical ScreenOS versions and license keys
  • Firewall’s with identical hardware
  • At least one interface on each firewall to be configured in the HA zone, which will be used for carrying control channel information

Configuration steps on the unconfigured Firewall.

Configure the Interface(s) for HA

If possible it makes sense to use the same Interface as used on the other device.

set interface ethernet0/4 zone HA

Configure the NSRP cluster id:

set nsrp cluster id 1

Both firewalls in the cluster must have the same Cluster ID number.

IMPORTANT: Other NSRP firewall pairs on the same segment must have a different set of cluster ids. Once the cluster id is set to a value, all the security interfaces will become part of the VSD-group 0, by default.

Configure cluster name for NSRP:

To define a single name for all cluster members, type the following CLI command:

set nsrp cluster name <name_str>
set nsrp vsd-group id <number> priority <number>

IMPORTANT: Make sure that the desired STANDBY firewall has a HIGHER priority configured than the preferred master. The firewall with the lower priority will be the active master in the cluster!

Physical connection:

Connect only the HA link cable to the interface that is configured for the HA zone.

Check the nsrp cluster status:

You can check the nsrp cluster status via the configuration GUI or via CLI.

To check the NSRP cluster status via GUI connect to the actual master and navigate to Reports > System Log > Event and search for NSRP related entries.

To check the NSRP cluster status via CLI please connect to the actual standby via console. You can check the status with the following command:

get nsrp cluster

Synchronize the configurations:

To synchronize the configuration from the active to the standby unit, please connect to the standby unit via console and execute the following command:

exec nsrp sync global-config save

The following will be reported shortly after you enter the above command:

load peer system config to save
firewall-B(B)-> Save global configuration successfully.
firewall-B(B)-> Save local configuration successfully.
firewall-B(B)-> Done.
firewall-B(B)-> Please reset your box to let cluster configuration to take effect!

Reset the Firewall:

IMPORTANT:  If you are prompted to save the configuration after you enter the reset command, answer n (No).  Then, proceed with the reboot by answering y (Yes).

firewall-B(B)-> reset
firewall-B(B)-> Configuration modified.  Save? [y]/n n
firewall-B(B)-> System reset.  Are you sure? y/[n] y

Check if the configurations are in sync:

Please execute the following command via CLI (console connection) on the backup firewall to check if the configurations are in sync:

exec nsrp sync global-config check-sum

Physical connection:

Please connect all other interfaces in the correct order to the standby unit.

Initial manual failover:

exec nsrp vsd-group 0 mode ineligible

Command reference:

NSRP

get nsrp cluster Show cluster info
get nsrp monitor Show list of monitored interfaces
get nsrp vsd id 0 Show VSD id 0
get counters ha Show HA interface hardware counters
exec nsrp sync global-config check-sum Allows you to see if the cluster configs are syncronised
exec nsrp sync global save Sync’s the nodes.A reboot is required to complete the update.
exec nsrp vsd-group 0 mode Fails over the cluster. Run this command on the Master node.

Current Settings / Values

get envar get environment variable
get config get device configuration
get system get system information
get arp get arp cache
get route get routing table

Block RFC1918 and RFC3330 IP ranges

I found on the Cisco website an interesting page about protecting core infrastructure which some of the network engineers do like blocking all RFC1918 private IP address ranges. But I never thought about blocking as well all RFC3330 special use IP address ranges.

I think it is worth sharing this information, see below the overview of all RFC1918 and RFC3330:

0.0.0.0/8            "This" Network
10.0.0.0/8           Private Use Networks
14.0.0.0/8           Public-Data Networks
24.0.0.0/8           Cable Television Networks
39.0.0.0/8           Reserved but subject to allocation
127.0.0.0/8          Loopback
128.0.0.0/16         Reserved but subject to allocation
169.254.0.0/16       Link Local
172.16.0.0/12        Private-Use Networks
191.255.0.0/16       Reserved but subject to allocation
192.0.0.0/24         Reserved but subject to allocation
192.0.2.0/24         Test-Net
192.88.99.0/24       6to4 Relay Anycast
192.168.0.0/16       Private-Use Networks
198.18.0.0/15        Network Interconnect Device Benchmark Testing
223.255.255.0/24     Reserved but subject to allocation
224.0.0.0/4          Multicast
240.0.0.0/4          Reserved for Future Use

I got the information directly from the RFC3330 page and it is worth having a look.

If you are a good network engineer you should block externally not only RFC1918 but as well RFC3330 address ranges because they should not traverse the public internet. Even blocking them for outbound traffic would be very useful.

Here an ASA object group:

object-group network rfc3330-subnets
  description Group of all rfc3330 subnets incl private and special use
  network-object 0.0.0.0 255.0.0.0
  network-object 10.0.0.0 255.0.0.0
  network-object 14.0.0.0 255.0.0.0
  network-object 24.0.0.0 255.0.0.0
  network-object 39.0.0.0 255.0.0.0
  network-object 127.0.0.0 255.0.0.0
  network-object 128.0.0.0 255.255.0.0
  network-object 169.254.0.0 255.255.0.0
  network-object 172.16.0.0 255.240.0.0
  network-object 191.255.0.0 255.255.0.0
  network-object 192.0.0.0 255.255.255.0
  network-object 192.0.2.0 255.255.255.0
  network-object 192.88.99.0 255.255.255.0
  network-object 192.168.0.0 255.255.0.0
  network-object 198.18.0.0 255.254.0.0
  network-object 223.255.255.0 255.255.255.0
  network-object 224.0.0.0 240.0.0.0
  network-object 240.0.0.0 240.0.0.0
  exit

Creating access-list entry on your outside and inside interface:

access-list acl_outside-inbound remark Blocking all rfc3330 ip address ranges
access-list acl_outside-inbound extended deny ip object-group rfc3330-subnets any

access-list acl_inside-outbound remark Blocking all rfc3330 ip address ranges
access-list acl_inside-outbound extended deny ip object-group rfc3330-subnets any

Here the links to both RFC1918 and RFC3330:

https://tools.ietf.org/html/rfc1918

https://tools.ietf.org/html/rfc3330