Upgrading ASA (5520) from 8.2(5) to 8.4(6)

Hi All,
I'm planing to upgrade my failover firewalls active/standby from 8.2.5 to 8.4.6. I read about the NAT and I think I'm ready for it cross fingers
My plane is
Upload the 8.4.6 and ASDM 7.1.3 for both firewalls then assgin the boot and ASDM image to the new files. After thaton the active firewall reload the standby and wait until its up and running (cross finger again) then force the active to be standby and reload the standby to get the new 8.4.6.
am I right about that? or should I upgrade to 8.3.1 or 8.3.1 first ?? please if it is, can you give me the full upgarde path?
Thanks in advance!!!

I don't know if I'm going to answer your question.  But here is my latest experience, about year ago.  I just preformed an upgrade from 8.0.x to 8.4.4.1 on a pair of ASA 5510's in failover using CLI.  The upgrade seem to go smooth from our end,  but all connection did drop.  We followed these steps here.  NAT wasn't an issue for us. 
Point is, there really isn't an upgrade path.  Just reload stand-by unit, make it the active unit and watch the connections.  Ours dropped don't know why.
Don't know if that helps,
Nick

Similar Messages

  • Upgrading ASA 5520

    Just received a new ASA 5520 and I'm trying to update the ASA s/w to 7.2 and the ASDM to 5.2. I have copied the files to flash, but when I run "asdm image flash:/asdm521.bin" I get an error that it's not an image file, and I don't know where to start with the ASA. Any help would be appreciated. I can't find any info in my documentation.

    Try this,
    To upgrade/install the ASDM follow the example procedure,
    ASA(config)# copy tftp flash
    Address or name of remote host [x.x.x.x]?
    Source filename [pix704.bin]? asdm-504.bin
    Destination filename [asdm-504.bin]?
    Accessing tftp://x.x.x.x/asdm-504.bin...!!!!!!!!!!!!!!!!!!!!!
    Writing file flash:/asdm-504.bin...
    5958324 bytes copied in 165.460 secs (36111 bytes/sec)
    ASA(config)#
    ASA(config)# sh flash
    Directory of flash:/
    7 -rw- 5437440 21:12:42 Nov 24 2005 pix704.bin
    11 -rw- 5919340 20:59:06 Nov 24 2005 asdm-504.bin
    13 -rw- 7017 14:00:58 Jul 22 2005 admin.cfg
    // asdm-504.bin is now copied in the flash. Now we need to set PIX to use
    // this image for loading ASDM.
    ASA(config)# asdm image flash:/asdm-504.bin
    // Last steps involve saving the running configuration to memory as we have
    // made changes to boot files and reloading the PIX.
    ASA(config)# write memory
    Building configuration...
    Cryptochecksum: d4f498de e877e418 2f9effa7 62ca0d6b
    4807 bytes copied in 3.20 secs (1602 bytes/sec)
    [OK]
    ASA(config)# reload
    // Once PIX comes back up, we can verify that upgradation has been successfull
    // by using "show version" command.
    Refer to the link ASDM Upgrade Procedure
    http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/products_tech_note09186a00804708d8.shtml#t8
    hope this helps.. all the best.. rate replies if found useful..
    Raj

  • Advice on upgrading ASA 5510 from version 8.4(4)1

    Hello all,
    Due to an issue we need to upgrade our ASA. Cisco Support team recommended upgrading to version 8.4.7, but, as we'll upgrade, we'd like to upgrade to version 9.
    We still use Cisco VPN Client for Remote Access VPNs so I'd like your advice on which version to install on ASA.
    Would you recommend version 9.0.3? 9.1.X?
    Thanks in advance,
    Igor

    We have a pretty huge ASA and ASASM complex, and we are just about finished upgrading from an assortment of 8.4.x, 8.5.x, and 8.6.x installs to 9.1.3 on everything. There is one gotcha on some systems in that there is a file system change or some sort of bug that is fixed in 8.4.5 I think. So you _may_ have to first upgrade to a newer version (8.4.7 would work) before going to 9.1.3.
    Our Cisco team has recommended going to version 9.x, and this is supported by recent tickets I've had on our stuff still running on 8.x, as the TAC engineer often says we need to upgrade to version 9.
    Four our setup, we had some fatal bugs in 8.4.6 and 8.4.7 that kept us running 8.4.5 for a very long time on some equipment.
    Anyway, I would recommend going to 9.1.3, which is one removed from the recently recleased 9.1.4. Our AnyConnect VPN complex has been on 9.1.3 for a few months now with no issues. Be sure to read the release notes thoroughly as 9.x changes some command contexts, new features, etc.
    Graham

  • Upgrading ASA 5510 from 8.0.4 to 8.2.5

    We want to implement Netflow so want to upgrade our 5510 to 8.2.5. But have a few questions.
    This device has 64MB of flash and 256MB of DRAM. Would I need to upgrade RAM? Right now we have about 25 site to site VPNs running through this thing as well as a few remote clients. Is this enough to constitute a memory upgrade?
    Right now we are running ASDM 6.4.7. Should we upgrade to a higher version?
    And lastly, would the upgrade to 8.2.5 require the use of AnyConnect for our VPN client users? Our 5505 is on version 8.2.5 and doesn't require AnyConnect, but wanted to make sure.
    Thank you for your time.

    Hi Michael,
    The RAM upgrade is needed if you want to go to 8.3+ code. Although you might find that you are running low on RAM and that will impact your ability to run packet captures, so an upgrade doesn't hurt...
    ASDM can be upgraded seperately and does not require a reboot + new ASDM versions are backwards compatible with older ASA codes...
    http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html#wp42231
    ASA 8.0(4)
    ASDM 6.1(3) and later.Recommended: 7.1(4).
    ASA 8.2(5)
    ASDM 6.4(3) and later.Recommended: 7.1(4).
    Although the Cisco VPN Client is eol and the replacement is AnyConnect, you are not forced to go that direction in any code...
    Patrick

  • Upgrade ASA Software from 8.3.2 to 8.4.3

    Hi,
    does anybody did an Upgrade from an 8.3 version to the new version 8.4.3 and can give some hints or links to read?
    I only have a production system and nothing to test and I don' want to get a nasty surprise...
    Thanks a lot in advance

    If you're already on 8.3(2) you've already gotten past the tricky bit - the new NAT syntax and access-list object use. There are some minor changes with identity NAT in going up to 8.4(3) as described here but that's about it as far as things to watch out for.
    The TAC is quite helpful and it is a good idea to open a case proactively just to have them on hand to take a quick look at any issues that come up. The TAC security team deals with these upgrades every day and is very adept at zeroing in on the root cause of  any issues you are having and setting things straight within in few minutes.

  • Zero downtime Upgrade ASA 8.0(4) TO 8.4(7)

    Hi All,
    I checked a few blogs and upgrading ASA 5520 from 8.0(4) to 8.4(7) following below path. I will be upgrading  RAM to 2GB at version 8.2.5. Reason for 8.4.6 is we may get an error message ""No Cfg structure found in downloaded image file" Error Message" if we upgrade directly to 8.4.7.
    Please advise if we can perform Zero downtime upgrade if I follow below path and will they still be in HA? Active/standby
    8.0.4-->8.2.5 (Active on 8.0.4 and standby 8.2.5)--> Will they be in HA?
    8.2.5--->8.4.6(Active on 8.2.5 and standby 8.4.6)--> Will they be in HA?
    I believe below one should not be a problem.
    8.4.6-->8.4.7(Active on 8.4.6 and standby 8.4.7)--> Will they be in HA?
    Thanks in advance.
    Regards

    8.0.4-->8.2.5 (Active on 8.0.4 and standby 8.2.5)--> Will they be in HA?
    HA will work...as in the units will failover.  But due to changes in configuration syntax you could run into problems with config synchronisation. And could also cause issues in traffic flow if a failover occurs.  So it is best to upgrade the second ASA to the new version ASAP.  It is also the reason cisco recommend using the same Major and Minor software versions.
    8.2.5--->8.4.6(Active on 8.2.5 and standby 8.4.6)--> Will they be in HA?
    Same as above.
    8.4.6-->8.4.7(Active on 8.4.6 and standby 8.4.7)--> Will they be in HA?
    This should be fine
    Please remember to select a correct answer and rate helpful posts

  • ASA 5520 Upgrade From 8.2 to 9.1

    To All Pro's Out There,
    I have 2 x ASA 5520 in Active/Standby state (Routed, Single context) running 8.2(3) image. They are working great and everybody is happy. Now it's time for us to upgrade to the latest and greatest version: 9.1 and as you know there are some architectural changes Cisco made to NAT statements and Access Lists. As one can tell, we have a monster environment in terms of NAT statements and access list that are currently configured on the appliances.
    In order to make the upgrade process "less" painful, I was able to find a loaner ASA 5520 device so I can practice the upgrade process offline and if needed, I use it in production (in conjunction with existing Primary and Secondary devices) should it be helpful. I currently don't have any plans on how to move forward with these 3 devices and put together an smooth upgrade. I am asking advice from experts that perhaps have done this in the past and know some Do's and Don’ts and can provide me some options toward getting best result: Minimum downtime and Smooth upgrade.
    I appreciate all the help in advance.

    Hi,
    My personal approach from the start has been to learn the new NAT configuration format on the ASA CLI and manually convert the configurations for the new ASA software. I am under the impression that the automatic conversion that the ASA does by rebooting straight into a new software level causes quite a lot of configurations and they arent really optimal.
    In your case it seems that you have a pretty much better situation than most people that dont have the chance to use a test device to test out the setup before actually putting it in production.
    What you can basically do is
    Insert the 8.2 configuration to the test ASA and boot it straight to the higher software levels and see what the conversion has done to the ASA configurations.
    You can use "packet-tracer" command to test if correct NAT rules are still hit after the conversion
    So far I have been lucky in the sense that most of the upgrades I have done have involved new hardware which has basically let me configure everything ready and just switch devices for the customer. So far everything has went really well and there has been only a 1-2 mistakes in NAT configurations because of misstyping some IP address or interface name which basically resulted from a lot of copy/paste when building the configurations. And these couple of mistakes have been from around 150 firewall migrations (of which most from FWSM Security Context to a ASA Security Context)
    If you have time to put into this then I would suggest you try to learn the new NAT format and write your NAT configurations yourself. Converting the existing configurations should essentially give you the tools to then maintain that firewall configuration easily in the future and apply that knowledge elsewhere.
    If you want to read a bit about the new NAT configuration format then I would suggest having a look at the NAT 8.3+ document I made:
    https://supportforums.cisco.com/docs/DOC-31116
    My personal approach when starting to convert NAT configurations for the upgrade is
    Collect all NAT configurations from the current ASA including any ACLs associated with the Policy type NATs and NAT0 configurations
    Divide NAT configurations based on type   
    Dynamic NAT/PAT
    Static NAT
    Static PAT
    NAT0
    All Policy Dynamic/Static NAT/PAT
    Learn the basic configuration format for each type of NAT configuration
    Start by converting the easiest NAT configurations   
    Dynamic NAT/PAT
    Static NAT/PAT
    Next convert the NAT0 configurations
    And finally go through the Policy NAT/PAT configurations
    Finally go through the interface ACLs and change them to use the real IP address as the destination in all cases since the NAT IP address is not used anymore. In most common screnarios this basically usually only involves modifying the "outside" interfaces ACL but depending if the customer has some other links to external resourses then its highly likely that same type of ACL changes are required on those interfaces also.
    The most important thing is to understand how the NAT is currently working and then configure the new NAT configuration to match that. Again, the "packet-tracer" command is a great tool to confirm that everything is working as expected.
    One very important thing to notice also is that you might have a very large number of Identity NAT configurations between your local networks interfaces of the ASA.
    For example
    static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0
    In the new software you can pretty much leave all of these out. If you dont need to perform NAT between your local interfaces then you simply leave out all NAT configurations.
    Naturally you can also use these forums to ask help with NAT configuration conversions. Even though its a very common topic, I dont personally mind helping out with those.
    So to summarize
    Try out the ASAs automatic configuration conversion when simply booting to new software levels on the test ASA you have
    Learn the new NAT configuration format
    Ask for help here on CSC about NAT configuration formats and help with converting old to new configurations.
    Personally if I was looking at a samekind of upgrade (which I will probably be looking at again soon) I would personally do the following
    Convert the configurations manually
    Lab/test the configurations on an test ASA
    During Failover pairs upgrade I would remove the Standby device from network, erase its configurations, reboot it to new software, insert manually written configurations.
    Put the upgraded ASA to the device rack and have cables ready connected to the customer devices if possible (or use existing ones)
    Disconnect currently active ASA running 8.2 and connect the new ASA to the network while clearing ARP on the connected routers to avoid any problems with traffic forwarding.
    Test connectivity and monitor ASAs connection and xlate tables to confirm everything is working
    Will add more later if anything comes to mind as its getting quite late here
    Hope this helps
    - Jouni

  • ASA 5520 upgrade from 8.4.6 to 9.1.2

    Dear All,
      I am having ASA 5520 in Active Standby failover configuration . I want to know if I can upgrade it from 8.4.6 to 9.1.2 using the zero downtime upgrade process mentioned on cisco site .
    Below is the process :
    Upgrade an Active/Standby Failover Configuration
    Complete these steps in order to upgrade two units in an       Active/Standby failover configuration:
    Download the new software to both units, and specify the new image to           load with the boot system command.
    Refer to           Upgrade           a Software Image and ASDM Image using CLI for more           information.
    Reload the standby unit to boot the new image by entering the           failover           reload-standby command on the active unit as shown           below:
    active#failover reload-standby
    When the standby unit has finished reloading and is in the Standby           Ready state, force the active unit to fail over to the standby unit by entering           the no           failover active command on the active unit.
    active#no failover active
    Note: Use the show             failover command in order to verify that the standby unit             is in the Standby Ready state.
    Reload the former active unit (now the new standby unit) by entering           the reload command:
    newstandby#reload
    When the new standby unit has finished reloading and is in the           Standby Ready state, return the original active unit to active status by           entering the failover           active command:
    newstandby#failover active
    This completes the process of upgrading an Active/Standby Failover       pair.
    Also after upgrade are there any changes required after IOS migration ( i.e are there any changes in the command line of 8.4.6 and 9.1.2 ) 
    It is mentioned on cisco site that
    Major Release
    —You can upgrade from the last minor           release of the previous version to the next major release. For example, you can           upgrade from 7.9 to 8.0, assuming that 7.9 is the last minor version in the 7.x           release. 

    Hi Tushar,
    The steps you mentioned are perfectly fine. There is no major difference in the commands of the 2 versions, it's just that in access-rule from 9.1 you have to any4 instead of any for ipv4 and any6 for ipv6. During conversion it will get convert automatically.
    Also, please refer to the following document (release notes of 9.1.2) for viewing the new features added in that version:
    http://www.cisco.com/en/US/docs/security/asa/asa91/release/notes/asarn91.html#wp685480
    - Prateek Verma

  • ASA 5520 Upgrade 8.0(4)-- 8.4.2--Zero Downtime

    Hello Everyone,
    We are currently on 8.0(4) and planning on upgrading our failover pair to 8.4.2, I read some documents saying that we can perform a zero downtime upgrade.
    According the below documents Version 8.2 supports mismatch memory failover,
    http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_overview.html#wp1077536
    https://supportforums.cisco.com/message/3549760#3549760//
    Upgrade Path:
    Active Firewall:                         Standby Firewall:
       8.0(4)                                       8.0(4)-->8.2.2
       8.0(4)                                       Upgrade RAM-2G---Reload
       faiover to standby                    8.2.2
       8.0(4)--->8.2.2                          8.2.2
       Upgrade RAM-2G-reload         8.2.2----Fail over
       8.2.2--Active                             8.2.2--Standby
      8.2.2                                          8.3.1
      8.2.2                                          8.4.2
      Failover to stanby                      8.4.2
      8.2.2--Standby                           8.4.2-----Active
    Can I perform zero downtime upgrade with the above upgrade path? Will both the firewalls act as a failover pair if one is on 8.2.2 and other is on 8.4.2.
    "Performing Zero Downtime Upgrades for Failover Pairs
    The two units in a failover configuration should have the same major  (first number) and minor (second number) software version. However, you  do not need to maintain version parity on the units during the upgrade  process; you can have different versions on the software running on each  unit and still maintain failover support."  (http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/admin_swconfig.html)
    Upgrade RAM-2G

    You can do it in a lot fewer steps.
    1. Upgrade RAM on standby, reload and make it active.
    2. Repeat process for newly standby unit.
    Now you have 2 units still on 8.0(4) with requisite RAM for 8.3+. TAC will recommend you go up in "baby steps" but the software will work upgrading directly from 8.0 to 8.4. 8.4(3) is the current version for the 5520 platform. At most conservative, I might upgrade to 8.2(4) as an interim but it's not strictly necessary. So my next step would be:
    3. Upgrade standby unit from 8.0(4) to 8.4(3). At this point take stock of the script syntax changes. Examine the upgrade log (on disk0:) and address any discrepancies.
    Note active/standby failover will work here but should not be run this way for any extended time as syntax changes would affect the ability to synchronize if changes are introduced on the active member.
    Finally:
    4. Flip upgraded standby unit to active and upgrade remaining standby unit to 8.4(3).
    If you follow these steps and check your work after each step, this would all be zero downtime.

  • ASA 5520 Software & Firmware Upgrades

    Is there a way to update the firmware / microcode on the ASA or SSM? I am planning on upgrading the ASA version from 7.2(2) to 8.0(4) and was wondering how, if at all, the firmware was ever upgraded too. The output from 'sh module' is below.
    ASA# sh module
    Mod Card Type Model Serial No.
    0 ASA 5520 Adaptive Security Appliance ASA5520-K8 JMX1044K1S9
    1 ASA 5500 Series Security Services Module-10 ASA-SSM-10 JAF10370340
    Mod MAC Address Range Hw Version Fw Version Sw Version
    0 0018.19eb.ba7d to 0018.19eb.ba81 1.1 1.0(11)2 7.2(2)
    1 000a.b89c.d12c to 000a.b89c.d12c 1.0 1.0(11)2 6.0(1)E1
    Mod SSM Application Name Status SSM Application Version
    1 IPS Up 6.0(1)E1
    Mod Status Data Plane Status Compatibility
    0 Up Sys Not Applicable
    1 Up Up
    ASA#
    Thanks,
    Timothy

    I would not recommend upgrading - search the posts for 8.0(4) - you will find alot of people have had issues.
    If there is no specific reason for the upgrade i.e feature enhancments, I suggest you stay on 7.2(2)

  • After i upgrade my ASA 5505 from 8.2 to 8.4 i can no longer connect to ASDM. showing connecting ..... please wait for hours now

    after i upgrade my ASA 5505 from 8.2 to 8.4 i can no longer connect to ASDM. showing connecting ..... please wait for hours now

    Ron
    I recently looked at this question with a customer who has been running 8.2 and needs to get some features in newer code. We decided that it made more sense to go to 8.4 than to 8.3.
    HTH
    Rick

  • ASA 5520 VERSION 8.2 UPGRADE TO 9.0

    Hello friends,
    I am considering to perform an upgrade of my ASA 5520 with versión 8.2 to 9.0, so I will enjoy the benefits of anyconnect for mobile devices. I clearly understand that I must pay special attention to:
    NAT Rules.
    RAM Memory: 2 GB.
    Adding the part numbers to power on the newest versions of anyconnect and for mobile devices
    L-ASA-AC-E-5520= ASA-AC-M-5520=
    am I missing any other thing? Flash requirement? Or to pay attention to some other configurations? 
    Any comment or documentation will be appreciated.
    Regards!

    You can run the latest AnyConnect client - including mobile clients - with those licenses even on an ASA with the current  8.2 code - 8.2(5) as of now. While it's a bit old and lacking some of the newer features, it's a solid and stable release.
    That would save you the trouble of migrating your NAT configuration (and other bits) and upgrading memory.
    Since the ASA 5500 series (5510, 5520 etc.) is past End of Sales you have a limited future on those platforms. For instance, ASA 9.1(x) is the last set of code releases that will be available for them. (The current software on the 5500-X is 9.3(1).)

  • ASA 5520: Retrieve user, group -and- lanlist (ACL) from openldap

    hi,
    while migrating from a VPN Concentrator 3000 to ASA 5520 (IOS 8.0.4), we'd like to put all VPN-related configuration settings in an openldap server (2.3.27).
    We have trouble finding ways to put group settings, LanLists (as they were called on the Concentratror, or ACLs) and Lan2Lan configurations in LDAP.
    Authenticating users through openldap works, and there seems to be a aaa-server command "ldap-group-dn-base", but it seems this is only used in conjunction with Active Directory, while we only use openldap.
    Furthermore, ACL's seem to be indices refering to ACLs locally stored on the ASA: how to put the complete ACL in LDAP?
    Preferred LDAP configuration:
    VPN-users: ou=users,dc=vpn,dc=COMPANY,dc=com
    VPN-groups: ou=groups,dc=vpn,dc=COMPANY,dc=com
    VPN-L2L: ou=lantolan,dc=vpn,dc=COMPANY,dc=com
    How to refer the ASA to an entry in ou=groups,... from an entry residing in ou=users?
    Same question for LanLists. Is this possible?

    Thank you. I did find the attribute map option, but the manuals and explanations that describe this feature all refer to group-settings (ACLs etc) that are _already configured_ on the ASA. They refer to a groupname or ACL-name that is "known" in the ASA configuration.
    What we'd like to do is put -all- possible group, ACL, lan2lanlists, data in ldap. So when a user authenticates:
    1. his user-credentials are checked against LDAP and relevant configurations (using attribute maps) are loaded into the ASA
    2. his group-credentials are checked against LDAP and relevant group-configurations (using attribute maps) are loaded into the ASA
    3. possible lan/network-lists to which his group-information refers, are loaded from LDAP into the ASA.
    Perhaps I'm missing something, but I've found only ways to put the _name_ (/ID) of these settings in LDAP, referring to settings/configurations already existing in the ASA. I'd like to put _all_ the settings/configurations in LDAP as well.

  • Problems after upgrading ASA from 8.4.5 to 9.1.1

    Hi,
    We are having problem with behavior of nat statement after upgrading ASA. Here are results of packet tracer in our testing environment:
    object network onBK028VRRP
    host 1.1.1.111
    object network onSIEMServers
    host 1.1.1.1
    object service osSyslog
    service tcp source eq telnet
    object-group network ognBK028ClientsOutside
    network-object 10.0.0.0 255.0.0.0
    nat (inside,outside) source static onBK028VRRP onSIEMServers destination static ognBK028ClientsOutside ognBK028ClientsOutside service osSyslog osSyslog
    ASA 8.4.5
    packet-tracer input OUTSIDE tcp 10.1.1.1 50000 1.1.1.1 80 detailed
    Phase: 1
    Type: ROUTE-LOOKUP
    Subtype: input
    Result: ALLOW
    Config:
    Additional Information:
    in   1.1.1.0         255.255.255.0   inside
    Phase: 2
    Type: ACCESS-LIST
    Subtype: log
    Result: ALLOW
    Config:
    access-group IZOUTSIDE in interface outside
    access-list IZOUTSIDE extended permit tcp any any eq www
    Additional Information:
    Forward Flow based lookup yields rule:
    in  id=0xce99ccc8, priority=13, domain=permit, deny=false
            hits=0, user_data=0xc91bc540, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
            src ip/id=0.0.0.0, mask=0.0.0.0, port=0
            dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, dscp=0x0
            input_ifc=outside, output_ifc=any
    Phase: 3
    Type: IP-OPTIONS
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    Forward Flow based lookup yields rule:
    in  id=0xcb53d948, priority=0, domain=inspect-ip-options, deny=true
            hits=42, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
            src ip/id=0.0.0.0, mask=0.0.0.0, port=0
            dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
            input_ifc=outside, output_ifc=any
    Phase: 4
    Type: IP-OPTIONS
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    Reverse Flow based lookup yields rule:
    in  id=0xcb561758, priority=0, domain=inspect-ip-options, deny=true
            hits=40, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
            src ip/id=0.0.0.0, mask=0.0.0.0, port=0
            dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
            input_ifc=inside, output_ifc=any
    Phase: 5
    Type: FLOW-CREATION
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    New flow created with id 43, packet dispatched to next module
    Module information for forward flow ...
    snp_fp_tracer_drop
    snp_fp_inspect_ip_options
    snp_fp_tcp_normalizer
    snp_fp_translate
    snp_fp_adjacency
    snp_fp_fragment
    snp_ifc_stat
    Module information for reverse flow ...
    snp_fp_tracer_drop
    snp_fp_inspect_ip_options
    snp_fp_translate
    snp_fp_tcp_normalizer
    snp_fp_adjacency
    snp_fp_fragment
    snp_ifc_stat 
    Result:
    input-interface: outside
    input-status: up
    input-line-status: up
    output-interface: inside
    output-status: up
    output-line-status: up
    Action: allow
    ASA 9.1.1
    packet-tracer input OUTSIDE tcp 10.1.1.1 50000 1.1.1.1 80 detailed
    Phase: 1
    Type: ROUTE-LOOKUP
    Subtype: input
    Result: ALLOW
    Config:
    Additional Information:
    in   1.1.1.0         255.255.255.0   inside
    Result:
    input-interface: outside
    input-status: up
    input-line-status: up
    output-interface: inside
    output-status: up
    output-line-status: up
    Action: drop
    Drop-reason: (no-route) No route to host
    Which option change this?
    BR,  M.

    Looks like you are hitting the following bug: CSCud64705
    http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCud64705

  • After upgrade of ASA software from 8.3.25 to 8.4.3,

    clientless SSL VPN users are denied connection.  Also, a pop up window appears with the following text message:
    "SSL VPN Relay mismatch, you need to log off Windows first."  Of course,  logging off and on WIndows per the message corrects the issue and
    allows the user to connect. 
    I am trying to understand why it is neccessary to log off Windows.  I can't say that I have seen this with prior upgrades i.e. from 8.2 to 8.3.
    Thanks in advance,
    Charles

    If you're already on 8.3(2) you've already gotten past the tricky bit - the new NAT syntax and access-list object use. There are some minor changes with identity NAT in going up to 8.4(3) as described here but that's about it as far as things to watch out for.
    The TAC is quite helpful and it is a good idea to open a case proactively just to have them on hand to take a quick look at any issues that come up. The TAC security team deals with these upgrades every day and is very adept at zeroing in on the root cause of  any issues you are having and setting things straight within in few minutes.

Maybe you are looking for