topic what is wrong with this NAT rule? in Network Security

what is wrong with this NAT rule?

Colin Higgins — Tue, 12 Mar 2019 04:25:18 GMT

I have a NAT rule that seems to be failing on my ASA

The host is on a DMZ interface. Let's call it ACME-DMZ

the nat rule looks like this

object network obj-172.31.150.41

host 172.31.150.41

nat (ACME-DMZ,outside) static 166.191.102.41

the access-list on the ACME-DMZ interface is permit ip any any (for troubleshooting)

the access-list on the outside interface permits tcp 443 to the "real" address 172.31.150.41

security level on ACME-DMZ interface is 40

security level on outside is 0

When I do a packet trace in ASDM it gets through the ACLs and routes, but fails on the NAT, saying "packet dropped."

It doesn't say anything else. What is the issue here?

more info: the error is an

Colin Higgins — Thu, 03 Jul 2014 22:24:49 GMT

more info:

the error is an "rpf-check" error

Hi Colin, What is the exact

nkarthikeyan — Fri, 04 Jul 2014 06:41:48 GMT

Hi Colin,

What is the exact statement you have given in the packet tracer statement.... you packet tracer command should be like this... Normally if you misconfigure your Packet tracer also gives wrong result.....

You NAT statement should be okay....

packet-tracer input outside tcp 1.1.1.1 2000 166.191.102.41 443 detailed

Also there is a bug in ASA 9.1 x versions for showing wrong packet tracer results...

Regards

Karthik

OK, the trace result is below

Colin Higgins — Fri, 04 Jul 2014 14:02:58 GMT

OK, the trace result is below. Basically, what is happening is that I have two hosts on the DMZ (172.31.150.40 & 41). Both are up and reachable from the firewall and both are in the same access-list (outside-in). .40 answers to pings and I can connect to its resources. The 172.31.150.41 server does not respond at all, and it looks like a NAT failure.

Here is the error in the log

Jul 04 2014 01:06:33: %ASA-4-313004: Denied ICMP type=0, from laddr 172.31.150.41 on interface ACME-DMZ to 73.50.84.166: no matching session

and here is the packet-trace

packet-tracer input outside tcp 1.1.1.1 2000 166.191.102.41 443$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff2dda45d0, priority=1, domain=permit, deny=false
        hits=2582579461, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0100.0000.0000
        input_ifc=outside, output_ifc=any

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network obj-172.31.150.41
nat (ACME-DMZ,outside) static 166.191.102.41
Additional Information:
NAT divert to egress interface ACME-DMZ
Untranslate 166.191.102.41/443 to 172.31.150.41/443

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside-in in interface outside
access-list outside-in extended permit tcp any host 172.31.150.41 object-group Lync-Edge-Outside log debugging
object-group service Lync-Edge-Outside tcp
description: Services for Lync Edge from outside
port-object eq https
port-object eq 5061
port-object range 50000 59999
port-object eq 3478
port-object eq www
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff2fa325c0, priority=13, domain=permit, deny=false
        hits=4, user_data=0x7fff270d3b00, 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=172.31.150.41, mask=255.255.255.255, port=443, dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff2dda9610, priority=0, domain=inspect-ip-options, deny=true
        hits=30557179, 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: 5
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff2ee9c110, priority=50, domain=ids, deny=false
        hits=2026601, user_data=0x7fff2e508830, 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=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fff2ea757f0, priority=13, domain=ipsec-tunnel-flow, deny=true
        hits=3667292, user_data=0x0, cs_id=0x0, 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: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network obj-172.31.150.41
nat (ACME-DMZ,outside) static 166.191.102.41
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fff2fcd8dc0, priority=6, domain=nat-reverse, deny=false
        hits=114, user_data=0x7fff2fa0f9a0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=172.31.150.41, mask=255.255.255.255, port=0, dscp=0x0
        input_ifc=outside, output_ifc=ISTHA-DMZ

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x7fff2fb26510, priority=0, domain=inspect-ip-options, deny=true
        hits=145553, 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=ISTHA-DMZ, output_ifc=any

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 32743408, 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_ids
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_ids
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat

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

a little more info: there is

Colin Higgins — Fri, 04 Jul 2014 14:08:13 GMT

a little more info:

there is another firewall on that subnet. could the host be replying out that firewall.

the host's default gateway is this ASA we are working with here.

is this public ip 166.191.102

nkarthikeyan — Fri, 04 Jul 2014 15:08:49 GMT

is this public ip 166.191.102.41 is dedicated for the server 172.31.150.41? If so then you should not have any issue with your NAT statement..... does firewall have a proper route to the server..... the other firewall firewall you have mentioned here right.... if that firewall is gateway of the host then you should have a proper routing and access rules allowed in that firewall......

Internet ---> (Out) <>ASA <>(DMZ)--------------->ASA(LAN)-->Server

In the above scenario you are doing NAT on the Internet ASA FW and server is in DMZ Zone where it has an another firewall inside the DMZ Zone.... You have already done NAT and Access Rules allowed in internet firewall..... in iNternet firewall you should have the static route to reach firewall....

say for eg: route ACME-DMZ 172.31.150.41 255.255.255.255 < DMZ ASA IP Address>

and in ASA DMZ you should have the routing pointed to internet ASA....

Regards

Karthik

OK, I have some more info: If

Colin Higgins — Mon, 07 Jul 2014 14:12:25 GMT

OK, I have some more info:

If I ping 166.191.102.40 from the outside I get a reply

if I ping 166.191.102.41 I see the traffic hitting the firewall and then dying on the trace with a "no matching session" error.

if I ping from 166.191.102.41 to the Internet through the firewall, I see the icmp traffic pass through the firewall to the outside, but nothing comes back.

If I ping from 166.191.102.41 to the internal network it works both ways.

So traffic seems to be "one way" to and from the host. I don't know why.

do you have inspect icmp in

nkarthikeyan — Tue, 08 Jul 2014 06:46:00 GMT

do you have inspect icmp in policy-map??? Also do you have the icmp allowed for that specific host??

Regards

Karthik