Solved: Route-lookup processed before Un NAT in ASA 5555x

thangtv01 · ‎01-12-2015

Hi all,

I have just migrate configure from PIX 535 OS ver 7.2 to ASA 5555x OS ver 9.1.(2) and have the problem:

I NAT IP 10.1.246.12 to different zone and create access-list to sqlnet on server, but when i do packet tracer, ASA always perform route-lookup before Un NAT so connection is dropped.

ASA# show  nat 10.1.246.12
Manual NAT Policies (Section 1)
166 (DB) to (Office) source static OBJ-10.1.246.12 OBJ-192.168.1.12
    translate_hits = 0, untranslate_hits = 0
167 (DB) to (Public) source static OBJ-10.1.246.12 OBJ-172.16.13.12
    translate_hits = 3, untranslate_hits = 3
168 (DB) to (Operator) source static OBJ-10.1.246.12 OBJ-10.1.249.12
    translate_hits = 4, untranslate_hits = 1
169 (DB) to (Test) source static OBJ-10.1.246.12 OBJ-10.1.254.12
    translate_hits = 2, untranslate_hits = 0
206 (DB) to (App) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0
236 (DB) to (OfficeSrv) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0
325 (DB) to (DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
    translate_hits = 0, untranslate_hits = 0

access-list acl_dmz extended permit tcp host 10.1.253.3 host 10.1.246.12 eq sqlnet

ASA# packet-tracer input dmz tcp 10.1.253.3 1000 10.1.253.12 1521

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.1.253.0      255.255.255.0   DMZ

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

I don't understand why ASA does not perform NAT like I configured. Can you help me please?

Thanks

Jouni Forss · ‎01-12-2015

Hi,.

With regards to NAT I would suggest reading Ciscos material regarding it and also searching online for different guides.

You can also take a look at the NAT document I wrote in 2013

https://supportforums.cisco.com/document/132066/asa-nat-83-nat-operation-and-configuration-format-cli

- Jouni

View solution in original post

Jouni Forss · ‎01-12-2015

Hi,

So seems you are doing a Static NAT from "DB" to "DMZ" and the NAT IP address is probably part of the directly connected subnet on interface "DMZ"?

Could you show us the output of

show xlate local 10.1.246.12

I would make sure that there is no typos in the actual "object" configurations used in the NAT. Normally I would expect the "packet-tracer" to match to the Static NAT (Manual NAT) that you have configured.

Its naturally possible that some bug is involved.

- Jouni

thangtv01 · ‎01-12-2015

Thank for your reply.

ASA# show xlate local 10.1.246.12
650 in use, 652 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from DB:10.1.246.12 to Office:192.168.1.12
    flags sT idle 175:20:12 timeout 0:00:00
NAT from DB:10.1.246.12 to Public:172.16.13.12
    flags sT idle 1:36:09 timeout 0:00:00
NAT from DB:10.1.246.12 to Operator:10.1.249.12
    flags sT idle 6:53:50 timeout 0:00:00
NAT from DB:10.1.246.12 to Test:10.1.254.12
    flags sT idle 79:10:42 timeout 0:00:00
NAT from DB:10.1.246.12 to App:10.1.246.12
    flags sIT idle 3:05:51 timeout 0:00:00
NAT from DB:10.1.246.12 to OfficeSrv:10.1.246.12
    flags sIT idle 3:05:51 timeout 0:00:00
NAT from DB:10.1.246.12 to DMZ:10.1.253.12
    flags sT idle 2:29:40 timeout 0:00:00

When I move NAT command to top NAT order = 3, It ok. But I want to know why.

ASA(config)# show nat 10.1.246.12
Manual NAT Policies (Section 1)
3 (DB) to (DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
    translate_hits = 0, untranslate_hits = 0
167 (DB) to (Office) source static OBJ-10.1.246.12 OBJ-192.168.1.12
    translate_hits = 0, untranslate_hits = 0
168 (DB) to (Public) source static OBJ-10.1.246.12 OBJ-172.16.13.12
    translate_hits = 3, untranslate_hits = 3
169 (DB) to (Operator) source static OBJ-10.1.246.12 OBJ-10.1.249.12
    translate_hits = 4, untranslate_hits = 1
170 (DB) to (Test) source static OBJ-10.1.246.12 OBJ-10.1.254.12
    translate_hits = 2, untranslate_hits = 0
207 (DB) to (App) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0
237 (DB) to (OfficeSrv) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0

ASA(config)# packet-tracer input dmz tcp 10.1.253.3 1000 10.1.253.12 1521

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DB,DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
Additional Information:
NAT divert to egress interface DB
Untranslate 10.1.253.12/1521 to 10.1.246.12/1521

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_dmz in interface DMZ
access-list acl_dmz extended permit tcp host 10.1.253.3 host 10.1.246.12 eq sqlnet
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (DB,DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
Additional Information:
Static translate 10.1.253.3/1000 to 10.1.253.3/1000

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: inspect-sqlnet
Result: ALLOW
Config:
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect sqlnet
service-policy global_policy global
Additional Information:

Phase: 7
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DB,DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 301494, packet dispatched to next module

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: DB
output-status: up
output-line-status: up
Action: allow

Jouni Forss · ‎01-12-2015

Hi,

Typical reason would be a overlapping NAT configuration that is of higher priority but in that case one would expect to see the original "packet-tracer" to fail in a later phase or have some UN-NAT Phase before.

It might be due to bug but can't naturally be sure.

If you want you could move the NAT rule back to the original spot and see if the problem with the NAT is present again. If it is then it would point to a configuration problem. If the problem did not appear again then it would seem like some bug. Judging by the numbering of the rules you do seem to have a large NAT configuration and its possible that some bug is related or just simply some NAT order.

If you happen to try the original setup (where the NAT did not work) can you also try "packet-tracer" from the direction of the host for which the NAT is performed? Would like to see what NAT (if any) is matched in that case (from DB to DMZ)

- Jouni

thangtv01 · ‎01-12-2015

Hi Jouni,

I still enter command NAT from DB to DMZ at last (at line 325), still have the same problem like the original post and still debug.

I have just change from PIX to ASA and I want to know deeply about NAT on ASA. So if you want me show any information please tell me and I will do it.

Thangtv

Jouni Forss · ‎01-12-2015

Hi,

Since the problem is present again after changing the NAT rule to the original place then I would like to see the "packet-tracer" command output.

packet-tracer input DB tcp 10.1.246.12 12345 <destination ip> <destination port>

You should insert some destination IP address and port that is allowed by the current ACL attached to the interface "DB". I would like to see to which NAT configuration the traffic matches WHEN the NAT configuration is at the original place and WHEN the simulated traffic is going towards the "DMZ" subnet.

- Jouni

Jouni Forss · ‎01-12-2015

Hi,.

With regards to NAT I would suggest reading Ciscos material regarding it and also searching online for different guides.

You can also take a look at the NAT document I wrote in 2013

https://supportforums.cisco.com/document/132066/asa-nat-83-nat-operation-and-configuration-format-cli

- Jouni

thangtv01 · ‎01-12-2015

Hi

Your link, I will read it carefully.

ASA(config)# packet-tracer input db tcp 10.1.246.12 12345 10.1.253.3 80

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.1.253.0      255.255.255.0   DMZ

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acl_db in interface DB
access-list acl_db extended permit tcp host 10.1.246.12 host 10.1.253.3 eq www
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (DB,DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
Additional Information:
Static translate 10.1.246.12/12345 to 10.1.253.12/12345

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect http
service-policy global_policy global
Additional Information:

Phase: 7
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DB,DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 304610, packet dispatched to next module

Result:
input-interface: DB
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow

ASA(config)#
ASA(config)# show nat 10.1.246.12
Manual NAT Policies (Section 1)
166 (DB) to (Office) source static OBJ-10.1.246.12 OBJ-192.168.1.12
    translate_hits = 0, untranslate_hits = 0
167 (DB) to (Public) source static OBJ-10.1.246.12 OBJ-172.16.13.12
    translate_hits = 3, untranslate_hits = 3
168 (DB) to (Operator) source static OBJ-10.1.246.12 OBJ-10.1.249.12
    translate_hits = 4, untranslate_hits = 1
169 (DB) to (Test) source static OBJ-10.1.246.12 OBJ-10.1.254.12
    translate_hits = 2, untranslate_hits = 0
206 (DB) to (App) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0
236 (DB) to (OfficeSrv) source static OBJ-10.1.246.12 OBJ-10.1.246.12
    translate_hits = 0, untranslate_hits = 0
325 (DB) to (DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12
    translate_hits = 1, untranslate_hits = 0

Jouni Forss · ‎01-12-2015

Hi,

Ok, so in the original NAT order the reverse direction when the DB host initiates the connection to DMZ the correct NAT rule is matched but not in the other direction.

I am afraid that this might be hard to troubleshoot unless I saw more of the configuration.

I can not say for certain but it feels like we are either dealing with some bug or your perhaps have some NAT configuration that uses "any" as a parameter. To my understanding "nat" commands that use "any" in the section that defines the interfaces used (for example (inside,outside) or (any,outside)) force the ASA to do a route lookup first. This again might result in the fact that the ASA determines that the destination IP address is located behind the DMZ interface. This again determines that we are talking about traffic that takes a U-turn on the DMZ inteface (traffic comes in and leaves the same interface) and again this means that the ASA might block the simulated traffic in the "packet-tracer" because you are missing the command "same-security-traffic permit intra-interface". You can check this with the command "show run same-security-traffic"

Maybe you should use the following commands

show run nat | inc any

show run nat | inc DB

And then go through the "nat" commands listed and try to find some command that might be causing this problem.

I personally avoid configuring all NAT configurations in the same Section since it causes problems with the order of the NAT configurations. You simply wont be able to insert all the NAT rules to the bottom without creating problems or NAT configurations that dont work.

I have gone through these things in the document I wrote.

- Jouni

Jouni Forss · ‎01-13-2015

Hi,

Did you have a chance to look at this issue further? Did you perhaps find the cause for the problem?

- Jouni

thangtv01 · ‎01-13-2015

Hi Jouni,

I don't use "any" as a parameter. DB zone and DMZ has a diffirent security level.

When I convert configuration of PIX to ASA, I use tool to determine what kind of NAT to use and it show twice NAT. And I read the configuration guide, command of twice NAT is similar to command of PIX (OS 7.1.2) so I chose twice NAT to convert.

After read your document, I decided to use object NAT because it "Network Object NAT behaves more like the older 8.2" and "Section 2 - The Default Static Rules for Single Hosts". In our topology, ASA used to separate zones and static NAT for every IP of server, we do not use dynamic NAT/PAT.

I backuped old configure which used twice NAT and spend all day replace it which object NAT. One twice NAT I replaced with one object NAT.

325 (DB) to (DMZ) source static OBJ-10.1.246.12 OBJ-10.1.253.12

object network OBJ-10.1.246.12-DB-DMZ
host 10.1.246.12
nat (DB,DMZ) static 10.1.253.12
exit

Now I check every rule with packet-tracer. I think It takes 2 day to complete checking every rule.

Thank you.