ASA Issues after Upgrade and Downgrade

Tercestisi
Tercestisi used Ask the Experts™
on
Upgraded ASA5510 Security+ from 8.0.4 to 8.2.5 over the weekend; strange things have happend since thing and I think it may have to do with NATing and xlates between inside and outside interfaces.

However, I downgraded back to 8.0.4 today and am still having odd issues:

1) Receiving logs like this: Deny inbound UDP from 10.1.XXX.2/1150 to 10.1.YYY.12/52000 on interface XYZ1B

Receiving roughly 10 per second; this traffic is legitimate as it's one of our production PC's that talks to other production PC's on another vlan.

I have the access rule:

access-list XYZ1B_access_in_1 extended permit ip any any
access-list XYZ1B_access_in_1 extended permit udp any any
access-list XYZ1B_access_in_1 extended deny ip any WAN_BLOCK 255.255.255.248

2) Since the upgrade, and now downgrade too, users on 10.1.BBB.0/24 cannot access 10.1.AAA.70, a single host on this VLAN... they can access all other hosts. This is a host that functions as our GoToMeeting appliance and visiting http there results in page not found. We can ping it and nslookup it fine. After upgrade to 8.2.4 I saw the erroneous nat translation errors; however after setting the ASA to load 8.0.4 I am still unable to reach, and not getting the portmap errors any longer.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Issue a "clear xlate" - see if that helps. If not, do a write mem and reload the ASA. Clear the arp cache (clear arp) on the swtich to which the ASA connects.

Post a full running config of the ASA, scrub the sensitive data.

Author

Commented:
Thanks for the reply.

Done and done; reloaded just an hour ago due to the downgrade.

Config is 2246 lines long; would take me a while to scrub.

Author

Commented:
This is what I'm seeing, repeating, every second in logs.

2|May 24 2012|12:16:36|106006|10.1.AAA.113|137|server-dc|137|Deny inbound UDP from 10.1.AAA.113/137 to server-dc/137 on interface ZZO
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX9.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX9.51/16000 on interface XYZ1B
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX3.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX3.51/16000 on interface XYZ1B
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX7.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX7.51/16000 on interface XYZ1B
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX5.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX5.51/16000 on interface XYZ1B
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX8.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX8.51/16000 on interface XYZ1B
2|May 24 2012|12:16:36|106006|XYZ1_VNC|16000|10.1.XX4.51|16000|Deny inbound UDP from XYZ1_VNC/16000 to 10.1.XX4.51/16000 on interface XYZ1B
2|May 24 2012|12:16:35|106001|10.1.X2.109|6936|VOIP_ICP1|6800|Inbound TCP connection denied from 10.1.62.109/6936 to VOIP_ICP1/6800 flags SYN  on interface XYZVOIP
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX9.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX9.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX9.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX9.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX3.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX3.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX3.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX3.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX7.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX7.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX7.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX7.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX5.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX5.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX5.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX5.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX8.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX8.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX8.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX8.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX4.12|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX4.12/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106006|10.1.XX6.2|XX50|10.1.XX4.11|52000|Deny inbound UDP from 10.1.XX6.2/XX50 to 10.1.XX4.11/52000 on interface XYZ1B
2|May 24 2012|12:16:35|106007|10.1.XX1.105|58500|DNS||Deny inbound UDP from 10.1.XX1.105/58500 to server-dc/53 due to DNS Query
2|May 24 2012|12:16:35|106007|PROD_DVR|1088|DNS||Deny inbound UDP from PROD_DVR/1088 to server-dc/53 due to DNS Query
2|May 24 2012|12:16:35|106007|10.1.XX1.254|64539|DNS||Deny inbound UDP from 10.1.XX1.254/64539 to server-dc/53 due to DNS Query
2|May 24 2012|12:16:35|106006|10.1.XX5.51|16000|10.1.XX9.51|16000|Deny inbound UDP from 10.1.XX5.51/16000 to 10.1.XX9.51/16000 on interface XYZ3B
2|May 24 2012|12:16:35|106006|10.1.XX5.51|16000|10.1.XX3.51|16000|Deny inbound UDP from 10.1.XX5.51/16000 to 10.1.XX3.51/16000 on interface XYZ3B
2|May 24 2012|12:16:35|106006|10.1.XX5.51|16000|10.1.XX7.51|16000|Deny inbound UDP from 10.1.XX5.51/16000 to 10.1.XX7.51/16000 on interface XYZ3B
2|May 24 2012|12:16:35|106006|10.1.XX5.51|16000|10.1.XX8.51|16000|Deny inbound UDP from 10.1.XX5.51/16000 to 10.1.XX8.51/16000 on interface XYZ3B
2|May 24 2012|12:16:35|106006|10.1.XX5.51|16000|10.1.XX4.51|16000|Deny inbound UDP from 10.1.XX5.51/16000 to 10.1.XX4.51/16000 on interface XYZ3B

Open in new window

Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Without copies of logs and running config, we're limited in our ability to help you.

Usually when the ASA logs a denial, if it's a result of an access-list it will say so. Look for that.

After you downgraded, did you have a backup of the ASA config (prior to the upgrade) that you can TFTP to the ASA?  With 2246 lines of commands, it might be difficult to determine what has changed - unless maybe you have a good 'diff' utility?

I'm not sure if I understand correctly about whether hosts on the 10.1.BBB.0/24 _can_ ping the host 10.1.AAA.70 successfully?

If not, have a 10.1.BBB.0/24 host run a persistent ping (i.e. ping -t) on host 10.1.AAA.70. Let it run for a while and scan the ASA logs for denials of this nature. The denial entries may give a clue as to why it's denied.  Sometimes it's asymmetric NAT rules, sometimes it's access-lists etc.

Author

Commented:
Yes, I understand; if you'd like particular sections of config it may be easier.

I did have a backup of config before upgrade, and have restored that config to downgraded image.

Hosts on the 10.1.BBB.0/24  can_ ping the host 10.1.AAA.70 successfully; nslookup on DNS works as well. HTTP via browser to .70 results in timeout and page not found. Works from other vlans, via RA VPN, via site-to-site tunnels, etc.
It almost appears as though there is no access-list setup to allow that traffic. Access-lists must be declaired and then applied to an interface i.e.
access-list dmz-access-in extended permit tcp any Inside-Network 255.255.255.0 eq www

Open in new window

...
access-group dmz-access-in in interface DMZ

Open in new window

Author

Commented:
There is though:

access-list XYZ1B_access_in_1 extended permit ip any any
access-list XYZ1B_access_in_1 extended permit udp any any
access-list XYZ1B_access_in_1 extended deny ip any WAN_BLOCK 255.255.255.248

I added the udp one just today, as I thought I might just be going crazy as ip should cover it.
Let me see the access-list that specifically applies to the traffic on the error logs. Then let me see how the access-list / access-group is applied to the interface.

Author

Commented:
This is vlan to vlan traffic, if that helps; and if I launch ASDM up and do a traffic analyzer, it does in fact get stuck at the ACL and points to the default rule of deny ip any any... not sure why it wouldn't fall under permit ip any any which is at spot #1?

Author

Commented:
OK; give me some time to copy and scrub... may be a bit while I juggle other responsibilities as well. Thanks for the help!

Author

Commented:
A quick note; these are sticking out to me, which I have not seen before:

Deny inbound UDP from 10.1.AA1.87/56979 to server-dc/53 due to DNS Query

There has literally been a gremlin in all of our networks, all week; very odd happenings all around.

Author

Commented:
Well I'll be; a texdiff showed some definite differences between my running-conf vs what I had backed up, even after reloading.

We're back to where we were last week, and all the errors rightfully went away.

Thanks for pointing me in the correct direction!

Author

Commented:
Supremely excellent, especially to diff the run-config with the backup I had from pre-upgrade.
Just in case - this artical may also apply to you:
https://supportforums.cisco.com/thread/2073366

It regards "same security interface" type traffic.

Author

Commented:
Yep,

same-security-traffic permit inter-interface

is what was missing and cleared it up.
Most Valuable Expert 2015

Commented:
Even though it's closed, one last comment:

The biggest upgrade challenge is between 8.2 and 8.3.  

Prior to upgrading from 8.0 to 8.2, I modified any lists that referenced IPs or subnets and changed them to object-groups.  This made the upgrade to 8.2 seamless.

The upgrade from 8.2 to 8.3 also went well but there are major changes that predominately affect how NAT rules are written and used as well as VPN access.

As a rule of thumb, prior to upgrading, save your running-config to disk0:/8.X.X-running-config so that you have it to go back to substituting "X" for the release and revision.

Author

Commented:
Thanks!

I knew of the major differences in going to 8.3+, but was not aware, looking through the release notes, of any major differences between 8.0 to 8.2. I thought object-groups had the larger predominance in 8.3+?
Most Valuable Expert 2015

Commented:
They do but they're used somewhat differently.  You'll find reading and understanding the configuration to be easier if you (after backing up your current configuration) make the changes prior to upgrading to 8.2.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial