ASA v9.1 -- disable flagged ACEs would not re-enable w/o reload
I recently moved our 5501 from v8.2 up to 9.1... And I have been getting used to the new format of the ACLs and NAT statemnts. But I have a puzzle that I can't seem to justify. Maybe others can help either with something I am doing wrong or maybe confirmation that this is a bug. I can't find any known bug reports on this or any field notices... but I wanted some feedback before opening a TAC case.
We were doing a server upgrade last night and we changed our external interface ACLs to set some of our permit rules to disabled while the server was being upgraded. After the upgrade we took off the disabled flag from the ACEs, but traffic was still being blocked. The logging output also confirmed that the asa still thought the rule was to block the traffic.
We had been using the ASDM interface for lazyness for flagging some ACEs as 'disabled' and then removing the flag. The 'sh run' output appeared fine, so I'm not sure if that should make a difference or not.
I even removed the access-group entry binding the ACL to the interface and reapplying it, but that stopped all inbound traffic. The only way we were able to restore access was to reload the asa without saving config changes.
Anyone else have any ideas?
Cisco Adaptive Security Appliance Software Version 9.1(2)
Device Manager Version 7.1(3)
Any help is appreciated.
Thanks! -Cheers, Peter.
*P.S. -- as a side note, immediately after the 8.2 -> 9.1 upgrade, we had some strange ACL behavior on some L2L vpn tunnels where all traffic on the L2L tunnel was being blocked and only deleting the entire ACL and reapplying it (using the same rules copy/pased from the startup-config with the same name) resolved the issue. Very bizzaare in my opinion.
I did go straight from 8.2 to 9.1... Sadly I hadn't come across any notices about that...
I had converted all my NAT/PAT statements into object groups, but I had not done that on the ACLs. I did change the ACLs to use the internal IP (I guess they call that the Real IP now) versus the public one as before. Do I need to conver the ACLs to use object groups too?
The part I found the most odd was that everything was working fine... it was the removing of the 'disable' flag on the ACE entries that didn't seem to take effect.
are there a lot of ACEs that you are trying to amend? You could go into the CLI copy out the ACEs in question, remove the ACEs from the ASA, and then re-add the ACEs without the flag and see if that works.
-- Please remember to select a correct answer and rate helpful posts
Site to Site IPSec VPN with Dynamic IP Endpoint is typically used when we have a branch sites which obtains a dynamic public IP from the Internet ISP. For example an ADSL connection.One important note is that Site-to-Site VPN with Dynamic remote routers P...
On R1, configure a key ring that defines the peer R3:Address: 184.108.40.206Local and remote pre-shared key: cisco R1(config)#crypto ikev2 keyring KRR1(config-ikev2-keyring)# peer R3R1(config-ikev2-keyring-peer)# address 220.127.116.11R1(config-ikev2-keyring-pee...
This document shows how to use the Port Radius NAS PORT Id Attribute in a compound condition to control access with 802.1X.A user jdoe is allowed to access the network only through the physical port FastEthernet 0/1 of the switch and the user jwhite is al...
This document provides a configuration example of Security Assertion Markup Language (SAML) Authentication on FTD managed over FDM. The configuration allows Anyconnect users to establish a VPN session authenticating with a SAML Identity Serv...
DMVPN Dual Hub Dual Cloud Pros and ConsProsNo single point of failureQuick failover if routing protocols are tunedLoad balancing is easyTraffic engineering is easyEasy to work with multiple ISPsConsNeed 2 tunnels per spokeConfiguration is more complicated...