Scenario: Host A (trusted side of firewall) needs to talk to a web server on port 443 (untrusted side) Trusted rule exists on the Cisco ASA - permit Host_A Web_SVR port 443

The trusted rule should allow Host A to talk to the web server on port 443 and also allow the return traffic for that session through the firewall due to the session being initiated by the trusted source.

Everywhere I have read that the ASA is state full and return traffic rule should not be needed.

The problem is in my specific situation the ASA is denying the return traffic due to the source/destination ip's and protocols being reversed.

The question is what configurations exist in the default setup that make the Cisco ASA act in a stateful manner?

Historical Information: The stateful manner was working previously. We did an OS upgrade and received a new baseline config around the same time a few months ago. This is around when the issue started. I'm thinking it's a possible bug in the new IOS or a necessary config was overlooked or didn't take with the new IOS.

I've compared the old config and new config and there were a few object/service type syntax changes which were updated prior to loading the new config. I did not notice any failed commands when the new configs were loaded.

If you have any suggestions as to what I should try to look for I would appreciate it.

Thanks J

  • This question is very unclear... please consider improving the question with specifics from your config / systems... feel free to obfuscate any IP addresses required Commented Aug 8, 2013 at 3:01
  • I'm unable to provide configs or go into very specific detail due to the nature of work. Commented Aug 8, 2013 at 12:50
  • 1
    Post your OS version (show version), IP configuration (show ip), firewall configuration (show run access-group) and finally show access-list Based on these outputs, we can figure it out quick.
    – laf
    Commented Aug 11, 2013 at 10:14
  • Which version did you upgrade from and to? If you changed major revisions, there could be significant differences in the configuration.
    – YLearn
    Commented Aug 11, 2013 at 15:29
  • Current Version 8.0(5) - We upgraded from 7.x can't remember the minor revision. Commented Aug 22, 2013 at 18:29

3 Answers 3


Can you post some configuration?

What you can do is perform a packet trace to see how it passes through the ASA:

ASA# packet-tracer input <trust-interface-name> tcp <src-addr> <src port> <dst ip> https

One thing to note is that the source port probably doesn't matter, so just use 1234

This should give you a step by step rundown of the operations the packet is going through, and where it's being blocked.

  • 1
    Caveat: packet-tracer only works if the ASA isn't in transparent mode Commented Aug 8, 2013 at 3:51
  • 1
    Note on the Caveat:ASA is in multiple context transparent mode. Commented Aug 8, 2013 at 12:49
  • OK, well then yes that won't help you.
    – Puglet
    Commented Aug 8, 2013 at 22:45

The issue has been resolved.

Problem was we upgraded the ASA OS version and the upgrade required a memory upgrade as well and memory usage was pegged at 100%. Memory upgrade is complete now and the stateful nature of the ASA has returned to normal.

Thanks for everyone's support.


Could be bilateral routing on the ASA. If you have redundant paths between the source/destination over the ASA via multiple interfaces, and the packet leaves via one interface, and the response comes back on a different interface, then it's not in the state table and the ASA will drop it. I've had this quite a lot due to a out of band management network causing complexities around routing, we ended up having to fix it using PBR.

The ACL's on the ASA do stateful by deafult, but it is possible to make an exception, can't remember how to do that off the top of my head, i'll have a look around and see if i can find it.


Not the answer you're looking for? Browse other questions tagged or ask your own question.