cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1013
Views
0
Helpful
1
Replies

ISSUES after upgrading ASA IOS from 9.1.1 to 9.2.2.4

Dulal Ray
Level 1
Level 1

 

 

1)    As per steps mentioned in release note & IOS upgradation document of Cisco we have upgraded Firewall IOS from 9.1.1 to 9.1.2 then from 9.1.2 to 9.2.2.4. Below are the links for the same.

 

Release Notes 9.2(X) --> http://www.cisco.com/c/en/us/td/docs/security/asa/asa92/release/notes/asarn92.html#pgfId-769104

Upgrade to ASA 9.2 --> http://www.cisco.com/c/en/us/td/docs/security/asa/asa92/upgrade/upgrade92.html#pgfId-51224

 

2)      Post Upgradation to IOS 9.2.2.4 we were observing below logs on Firewall

 

2014-12-27 02:34:10        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:10: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:12        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:12: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:13        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:13: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.138 on interface OUTSIDE-INTF

2014-12-27 02:34:13        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:13: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:16        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:16: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.138 on interface OUTSIDE-INTF

2014-12-27 02:34:22        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:22: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.138 on interface OUTSIDE-INTF

2014-12-27 02:34:24        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:24: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.69 on interface OUTSIDE-INTF

2014-12-27 02:34:27        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:27: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.69 on interface OUTSIDE-INTF

2014-12-27 02:34:29        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:29: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:32        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:32: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:33        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:33: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.69 on interface OUTSIDE-INTF

2014-12-27 02:34:35        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:34: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.194 on interface OUTSIDE-INTF

2014-12-27 02:34:37        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:37: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.194 on interface OUTSIDE-INTF

2014-12-27 02:34:38        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:38: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.3.68 on interface OUTSIDE-INTF

2014-12-27 02:34:39        Local4.Critical     mumgff03-a       Dec 27 2014 02:34:39: %ASA-2-106016: Deny IP spoof from (103.23.24.128) to 172.27.166.138 on interface OU

 

Also, all traffic which was using default NAT rule “If you do not configure NAT for a given set of traffic, that traffic will not be translated, but will have all of the security policies applied as normal.” was not working.

 

Below are our observation while troubleshooting the issue:

 

-          Access required was between Inside Network to DMZ Network.

-          DMZ subnet is the connected subnet of DMZ Interface, DMZ Interface was UP and working fine.

-          While trying to access services hosted in DMZ Zone from Inside Network, it was observed instead of preferring DMZ Interface as exit interface OUSIDE Zone Interface was preferred.

-          Above issues got resolved after adding Identity NAT rule for entire DMZ Zone subnet. Which was against the default behavior of ASA 9.2.2.4 IOS “If you do not configure NAT for a given set of traffic, that traffic will not be translated, but will have all of the security policies applied as normal.”

-          As it was not feasible to add identity rules for all traffic using default NAT behavior we downgraded IOS one step down from 9.2.2.4 to 9.1.2. Post which all default NAT related issues got resolved.

-          On 9.1.2 IOS we started facing issue with all NAT section 1 & section 2 related traffic.

-          All traffic matching NAT section 1 & section 2 were not being forwarded by Firewall. All traffic matching section 3 was working fine.

-          Section 3 had a NAT rule as, all traffic flowing between INSIDE ZONE & OUSIDE ZONE not matching section 1 & 2 NAT rules will PAT to firewalls OUTSIDE ZONE Interface IP.

-          At the same time packet-tracer tool of ASA was showing traffic as allowed. 

-          Removing section 1 & section 2 rules resolved the issue, all the traffic was preferring section 3 rule, which was very unexpected behavior.

-          To resolve above issue we downgraded IOS from 9.1.2 to 9.1.1.

-          Post downgrading to original IOS all the issues got resolved.

 

Can any please tell if there is any BUG related to this?

1 Reply 1

Vibhor Amrodia
Cisco Employee
Cisco Employee

Hi,

I can tell you from experience that there are some NAT fixes which have changed the NAT order of operations and might welkl be the root cause ofr the issue that you were seeing.

I would like to know if you can share some outputs of the NAT statements with which you saw the issue and some logs or packet traces so that we can isolate the issue to a specific NAT statement.

Thanks and Regards,

Vibhor Amrodia

Review Cisco Networking for a $25 gift card