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

Configuration re-sync Juniper ISG NSRP cluster

When the ISG cluster devices are correctly configured, they will start synchronizing the configuration. You can check if the configurations is in sync with the following command:

Cluster1:fw01(M)-> exec nsrp sync global-config check-sum     
configuration in sync

It can happen from time to time that the configuration of the cluster run out of sync:

Cluster1:fw01(M)-> exec  nsrp sync global-config check-sum 
Warning: configuration out of sync

To solve this issue, you should force the configuration sync (only on the backup device!!!!):

Cluster1:fw02(B)-> exec nsrp sync global-config save
load peer system config to save
Save global configuration successfully.
Save local configuration successfully.
done.
Please reset your box to let cluster configuration take effect!

Cluster1:fw02(B)-> reset 
System reset, are you sure? y/[n] y
In reset ...

After the reboot of the backup device, the cluster should be fully operational and in sync.

Note : when the device prompts you to save the config, enter “n” (no)