Follow up from this tweet. Every time I tried to connect to the ASA’s ASDM Java would crash with a Null Pointer exception, I tried everything from deleting the .asdm folder in my home directory (my documents on windows), uninstalling the asdm launcher didn’t help, neither did clearing java’s cache or uninstalling and re-installing java.

In the end i had to downgrade, very frustrating!

I’ve been implementing a few Cisco ASA’s recently, and I blogged about this strange behavior; well I came across another one yesterday.

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 came accross something odd the other day, I had some Cisco IP Phones on a DMZ interface and the Call Manager was behind the inside interface. If you made a call from a 7940 to a 7940 everything worked fine, if you made a call from a 7905 to a 7940 it failled!

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!

I tweeted a little while ago about Nokia recently supporting interface failover within IPSO, well it looks like Cisco’s ASA Version 8 software can do it now too!

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

One of the interesting things about ASA’s is the fact that it supports running two OSPF Processes. This was a great decision by cisco, if a business has two different OSPF domains the chances are they are owned by two separate parts of the business, so where would be a better place to put a firewall?

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 !