Nat reverse path failure

[mahesh18]

Hi everyone,

I have config  bidirectional  ACL from inside to DMZ

inside(10.71.35.245)----ASA-----DMZ(192.168.134.33) port 389

packet tracer works fine

and now I config ACL

DMZ(192.168.134.33)----------ASA-----------inside(10.71.35.245) port 51173

packet tracer shows

#  packet-tracer input dmz tcp  192.168.134.33  1024 10.71.3$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.71.35.0      255.255.255.0   inside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.134.0   255.255.255.0   dmz

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group dmz in interface dmz
access-list dmz extended permit tcp host 192.168.134.33 10.71.35.245 eq 51173 log

Additional Information:

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

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

Phase: 7
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
  match ip inside host10.71.35.245 dmz any
    static translation to 192.168.134.72
    translate_hits = 58509, untranslate_hits = 749704
Additional Information:

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

[Kornelia Gutierrez]

Hi Maesh,

The problem is related to the nat rules in place:

- You are telling the ASA that when   inside host 10.71.35.245 tries to reach something on the dmz network, the host will be translated to 192.168.134.72. That is fine, the only inconvenient that you face is that when some host on the dmz  tries to reach inside host 10.71.35.245 using its real ip address (the 10.71.35.245) the asa will check the the original path and the returning path  to make sure the nat and routing is symmetric, so  the scenario will  look like this:

-From DMZ host 192.168.134.33 is trying to reach host 10.71.35.245

At this phase the  firewall will check routing and ACL in place, it will forward the traffic towards the inside using the following information:

source 192.168.134.33

destination 10.71.35.245

-On the inside side host 10.71.35.245 will receive the traffic and it will respond to the dmz host and it will send the traffic to the ASA with the following information

source 10.71.35.245

destination 192.168.134.33

-At this point the packet enters the inside interface and the ASA starts checking routing, nat and acl information for host 10.71.35.245, and he realizes that there is a nat for that host when it goes to the dmz:

static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255

So he will try to nat host 10.71.35.245, but then he also check his connection table and he realizes that the connection is like this:

DMZ                                Inside

 S 192.168.134.33 --- > D 10.71.35.245 

what the ASA will expect as a reply or return traffic is the following:

Inside                     DMZ

S 10.71.35.245 --> D 192.168.134.33

However the nat is telling the ASA to translate host 10.71.35.245 to 192.168.134.72

So the attempted reply will look like this

S 192.168.134.72 (10.71.35.245 NAT´D IP) ---> D 192.168.134.33

The ASA realizes that the above is a different from what he is expecting the connection to be, the communication is meant  between host 10.71.35.245 and 192.168.134.33 not between 192.168.134.72  (10.71.35.245 NAT´D IP) and 192.168.134.33, for that reason he notices that the return traffic flow is not the same and drops the packet.

In order to fix this, if you need to access from the DMZ side the inside host using its real ip address wich is 10.71.35.245 you will need to build another  nat.

For example

access-list inhost permit ip host 10.71.35.245 host 192.168.134.33

static (inside,dmz)  10.71.35.245 access-list inhost

Make sure that the given rule is above of the following nat:

static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255

Hope this helps.

[mahesh18]

Thanks for very great and detailed explanation.

I already have ACL from DMZ to inside that allows source 192.168.134.33 to access inside host 10.71.35.245.

This ACL is applied on DMZ interface.

Which nat config should I use?

Regards

MAhesh

[Kornelia Gutierrez]

Hi Mahesh,

You are very welcome!

Take the following NAT as an example:

access-list inhost permit ip host 10.71.35.245 host 192.168.134.33 

This acl is not applied in any interface, its purpose is to tell the ASA to not translate the inside host 10.71.34.245 only when is trying to communicate with 192.168.134.33.

static (inside,dmz)  10.71.35.245 access-list inhost

This type of nat is called static policy nat

[mahesh18]

so if I use this ACL and NAT then it should not cause any outage if traffic is flowing between host servers in DMZ

and inside right?

Another way

1>Can I use the ACL from DMZ  to inside where destination IP is 192.168.34.72 instead of 10.71.35.245?

current NAT for traffic flow from  inside to DMZ where packet tracer works fine is

Phase: 7
Type: NAT
Subtype:
Result: ALLOW
Config:
static (inside,dmz) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
  match ip inside host 10.71.35.245 dmz any
    static translation to 192.168.134.72
    translate_hits = 58509, untranslate_hits = 749693
Additional Information:
Static translate 10.71.35.245/0 to 192.168.134.72/0 using netmask 255.255.255.255

Phase: 8
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 192.168.134.72 10.71.35.245 netmask 255.255.255.255
  match ip inside host 10.71.35.245 outside any
    static translation to 192.168.134.72
    translate_hits = 0, untranslate_hits = 0
Additional Information:

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

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

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: dmz
output-status: up
output-line-status: up
Action: allow

is there any nat config that I can use instead of using that ACL?

Regards

Mahesh

[Kornelia Gutierrez · Accepted solution]

Hi Mahesh,

The nat should not cause an outage since is only meant betweent the specific inside and Dmz host.

The packet looks fine because in that example the connection is sourced by the inside, another thing you could do is try to access from the DMZ the 192.168.34.72 instead of the real ip address which is 10.71.35.245

[mahesh18]

Hi,

From inside to DMZ all is ok.

Can I use this ACL for traffic flow from DMZ to inside

1>Can I use the ACL from DMZ  to inside where destination IP is 192.168.34.72 instead of 10.71.35.245?

[Kornelia Gutierrez · Accepted solution]

Hi Mahesh,

Yes you can try that =)

[mahesh18]

try that still no luck.

when I try the policy nat it shows that address is used in static nat?

Is there any other way I can fix this?

Regards

Mahesh

[mahesh18]

I need to make two ACL from DMZ  to fix the issue

Regards

MAhesh