ASA Issues after Upgrade and Downgrade
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.
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.
ASKER
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.
Done and done; reloaded just an hour ago due to the downgrade.
Config is 2246 lines long; would take me a while to scrub.
ASKER
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 XYZ3BASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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 wwwaccess-group dmz-access-in in interface DMZASKER
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.
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.
ASKER
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?
ASKER
OK; give me some time to copy and scrub... may be a bit while I juggle other responsibilities as well. Thanks for the help!
ASKER
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.
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.
ASKER
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!
We're back to where we were last week, and all the errors rightfully went away.
Thanks for pointing me in the correct direction!
ASKER
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.
https://supportforums.cisco.com/thread/2073366
It regards "same security interface" type traffic.
ASKER
Yep,
same-security-traffic permit inter-interface
is what was missing and cleared it up.
same-security-traffic permit inter-interface
is what was missing and cleared it up.
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-confi
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-confi
ASKER
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+?
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+?
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.
Post a full running config of the ASA, scrub the sensitive data.