In my frustration I have given up and created a shell script which converts a CSV into an ASA output, simply create a two column CSV with Col A containing your starting IP and Col B containing you end IP.

The script is a recursive loop so should support large outputs such as 10.1.2.10 to 10.2.1.20 howvere I’m not actually sure you’d want that in your firewall config but I wrote the computability for the fun it!

Have fun, click “more” below if you can’t see the script!

#!/bin/bash

# Commas separated VAR....
IFS=","
while read name firstip lastip
# Loop around CSV
do

# Split up our first ip into it's octects
firstipfirstoctect=$(echo $firstip | awk -F "." '{print $1}')
firstipsecondoctect=$(echo $firstip | awk -F "." '{print $2}')
firstipthirdoctect=$(echo $firstip | awk -F "." '{print $3}')
firstipforthoctect=$(echo $firstip | awk -F "." '{print $4}')

# Split up our last IP into it's ocects
lastipfirstoctect=$(echo $lastip | awk -F "." '{print $1}')
lastipsecondoctect=$(echo $lastip | awk -F "." '{print $2}')
lastipthirdoctect=$(echo $lastip | awk -F "." '{print $3}')
lastipforthoctect=$(echo $lastip | awk -F "." '{print $4}')

	# Re-set BASH
	unset IFS 

	# Echo out the object GROUP name
	echo "object-group network $name"

	# Loop through 1st Octect
	for a in `seq $firstipfirstoctect $lastipfirstoctect`;
	do
		# test to see if we need to print the whole range
		if [ $firstipfirstoctect -lt $lastipfirstoctect ]
		then
			firstipsecondoctectCOUNTER="0"
			lastipsecondoctectCOUNTER="255"
		fi

		# first IP might not be 1
		if [ $a -eq $firstipfirstoctect ]
		then
			firstipsecondoctectCOUNTER=$firstipsecondoctect
		fi

		# last IP might not be 255
		if [ $a -eq $lastipfirstoctect ]
		then
			lastipsecondoctectCOUNTER=$lastipsecondoctect
		fi

			# Loop through 2nd Octect
			for b in `seq $firstipsecondoctect $lastipsecondoctect`;
			do

				# Same tests as before except, next octect.
				if [ $firstipsecondoctect -lt $lastipsecondoctect ]
				then
					firstipthirdoctectCOUNTER="0"
					lastipthirdoctectCOUNTER="255"
				fi

				if [ $b -eq $firstipsecondoctect ]
				then
					firstipthirdoctectCOUNTER=$firstipthirdoctect
				fi

				if [ $b -eq $lastipsecondoctect ]
				then
					lastipthirdoctectCOUNTER=$lastipthirdoctect
				fi

					# Loop through 3rd Octect
					for c in `seq $firstipthirdoctectCOUNTER $lastipthirdoctectCOUNTER`;
					do

						# copy / paste / tweak
						if [ $firstipthirdoctect -lt $lastipthirdoctect ]
						then
							firstipforthoctectCOUNTER="0"
							lastipforthoctectCOUNTER="255"
						fi

						if [ $c -eq $firstipthirdoctect ]
						then
							firstipforthoctectCOUNTER=$firstipforthoctect
						fi

						if [ $c -eq $lastipthirdoctect ]
						then
							lastipforthoctectCOUNTER=$lastipforthoctect
						fi

							# final octect... echo result.
							for d in `seq $firstipforthoctectCOUNTER $lastipforthoctectCOUNTER`;
							do
								echo " network-object $a.$b.$c.$d  255.255.255.255"
							done

					done
			done
	done

done<./FirewallRanges.csv

You can now configure access rules that are applied globally, as well as access rules that are applied to an interface. If the configuration specifies both a global access policy and interface-specific access policies, the interface-specific policies are evaluated before the global policy.

The following command was modified: access-group global

For users/companies which have migrated from Check Point to Cisco (usually to save on licensing fees), getting their head around a new interface level policy rather than a system (global) level is usually a bit of a challenge.

I’m looking forward to seeing if this really helps with policy migrations!

In the end i had to downgrade, very frustrating!

Take a look at this debug arp….

CiscoASA# debug arp
debug arp  enabled at level 1
CiscoASA#
CiscoASA# arp-set: added arp outside 192.168.1.122 001e.7000.1234 and updating NPs at 4301321940
arp-set: added arp inside 192.168.1.61 001a.7100.1234 and updating NPs at 4301321940

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.120 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.120, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.120 001e.7a51.1234 to 192.168.1.125 001a.3000.1234

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.73 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.73, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.73 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.69 001e.7a51.1234

arp-in: rqst for me from 192.168.1.125 for 192.168.1.69, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.69 001e.7a51.1234 to 192.168.1.125 001a.3000.1234

arp-in: request at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.123 001e.7a51.1234
arp-in: rqst for me from 192.168.1.125 for 192.168.1.123, on outside
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
arp-in: generating reply from 192.168.1.123 001e.7a51.1234 to 192.168.1.125 001a.3000.1234
arp-in: response at outside from 192.168.1.125 001a.3000.1234 for 192.168.1.125 ffff.ffff.ffff
arp-in: updating gratuitous ARP 192.168.1.125 - 001a.3000.1234
arp-set: added arp outside 192.168.1.125 001a.3000.1234 and updating NPs at 4301326660
CiscoASA#

The firewall is replying to arp requests even though both the source & destination of the traffic are on the same (outside) interface, now I haven’t manged to work out why the firewall was doing this, but I did find a fix on the cisco forums.

sysopt noproxyarp outside

Names, IPs & MAC’s have been changed to protect the innocent.

I ran a packet capture and found that the phone was “bouncing” the RTP stream off the firewall rather than connecting directly to the peer phone… very weird! The problem was solved by enabling…

same-security-traffic permit intra-interface

I thought I post this for some future googlers!

The following example creates two redundant interfaces:

asa(config)# interface redundant 1
asa(config-if)# member-interface gigabitethernet 0/0
asa(config-if)# member-interface gigabitethernet 0/1
asa(config-if)# interface redundant 2
asa(config-if)# member-interface gigabitethernet 0/2
asa(config-if)# member-interface gigabitethernet 0/3

Reference: Adding a Redundant Interface

I’ve put together a basic lab / config to test out the functionality, obviously this doesn’t address IP conflicts which are quite likely to happen in a real world scenario, but you do get the general idea. In my cisco config directory you’ll find two router configs and an ASA config. Each router is intended to represent each ospf domain, the ASA will then re-distribute the routes into each process… Note: you’ll see some “show” commands at the end of the config files.

I actually put this together as a “just in case” type thing, but I expect this to come in very handy in the future !