07-03-2014 03:07 PM - edited 03-11-2019 09:25 PM
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?
Solved! Go to Solution.
07-04-2014 08:08 AM
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
07-03-2014 03:24 PM
more info:
the error is an "rpf-check" error
07-03-2014 11:41 PM
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
07-04-2014 07:02 AM
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
07-04-2014 07:08 AM
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.
07-04-2014 08:08 AM
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
07-07-2014 07:12 AM
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.
07-07-2014 11:46 PM
do you have inspect icmp in policy-map??? Also do you have the icmp allowed for that specific host??
Regards
Karthik
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide