Again ASA v8.3 static and dynamic PAT Issues

[m.kafka]

The new nat behaviour is really irritating:

I had the following nat configuration running successfully for a couple of days and after a reboot due to power outage it was not forwarding traffic anymore:

object network VirusWall
host (private address).11

nat (dmzside,outside) source static DmzsideLan DmzsideLan destination static VpnAdminLan VpnAdminLan description Nat excemption VPN

nat (outside,dmzside) source static any any destination static interface VirusWall service smtp smtp unidirectional

object network VirusWall
nat (dmzside,outside) dynamic interface

I need both: dynamic PAT to the outside interface for outbound connections and static PAT inbound for smtp, so it looked quite convenient to do it this way.

(acl/access-group are ok - no need to go into this...)

The nat (outside,dmzside) is basically ok: if a connection is initiated on the outside interface from any to outside/tcp/25 then translate the connection to "source any" dest viruswall/tcp/25 on interface dmzside ... it worked for a couple of days.

After the power outage the packet tracer gave me an error message similar to "PHASE 2 ACL DENY due to implicit rule" but none of the configured deny statements had hit counts and real-time log did not show anything at all (severity level 6).

Logging monitor 7 showed a "tcp denied on interface outside" without further details for the inbound tcp/25.

after changing the unidirectional to "both" the static PAT was ok again. I know for sure that I did "wr mem" after configuring but after the reboot the original config didn't work anymore...

PS I prefer the global nat commands over object nat, its better to read in my eyes and gives better control over what's happening in detail and in my projects I often need a more granular config the top-down processing, first match give a lot of control...

PPS: I really dislike the objec-nat and try to avoid it whenever I can

[mirober2]

Hello,

The unidirectional bug that you're running into, CSCti36048, only affects the automated configuration migration process. Therefore, if you're sure you did a 'write mem' before the reload happened, that keyword shouldn't have come back.

If you schedule some time to reload the ASA again, does the problem reoccur? If yes, I would suggest opening a TAC case so this behavior can be investigated. Otherwise, double check the ASA's startup configuration and make sure that the 'unidirectional' keyword is not present anywhere. If you can confirm that, you should be safe from this problem on the next reload.

Hope that helps.

-Mike

[m.kafka]

Hi Mike, and thx for looking into it,

I have archived a snapshot of the config a couple of days ago and it is clearly "unidirectional" in the saved config. ANd it was clearly working for a couple of days. The customer would have panicked without incoming e-mail for a some days. And I verified the inbound static PAT after configuring.

Also I'm absolutely positive that I did write mem - BTW the running config after the power failure was exactly the same like the archived snapshot from the initial config and the static PAT still had the "unidirectional" in the running config after the power failure.

The unidirectional was to limit effects on other nat statements like the object dynamic PAT.

Like I said: since the reboot the static PAT needs to be "both directions" e.g. without the "unidirectional" to work.

Mysterious because to my understanding a static pat for inbound is sufficiently configured with the "unidirectional" for inbound sessions to be established. Outbound sessions are covered with the object dynamic PAT you see im my config.

ASA 8.3 still freaks me out from time to time...

(although I start to appreciate the advantages)

Rgds,

MiKa

PS: I dont get the %ASA-5-305013: Asymmetric NAT rules matched for  forward and reverse flows; Connection for icmp src Outside:192.168.1.5  dst inside:10.10.5.20 (type 8, code 0) denied due to NAT reverse path  failure

The ASA doesn't establish the connection in the first place... "TCP packet denied" before anything is evaluated, no acl-drop, no "cannot find translation slot for..."

PPS: For a reason I don't understand it works now with the unidirectional removed but it worked before with the unidirectional...

I'm mostly trying to understand what the issue is, the unidirectional is to my understanding only for establishing the connection, once it's established it should forward packets of that connection in both directions.

Message was edited by: m.kafka