topic Re: FTD NAT Matching in Network Security

FTD NAT Matching

Warren Sullivan - Corp — Fri, 21 Feb 2020 17:14:01 GMT

Hi Guys,

Another NAT related question, i have a need to do some funky translations from our DMZ to the inside of our network for our migration, below is the topology for the lab environment that I'm testing this stuff on, the red line indicates the path of translation, below the image is the NAT rule and ACP Rule i have created to make it happen, at the very bottom is the actual question i have....if you make it that far 🙂

Topology

NAT Rule

ACP Rule

What needs to happen is a Full NAT, source and destination translation;

A Web call from Ubuntu-2 in the DMZ_Zone (172.16.1.100) destined for IP 172.16.1.200 is to have the source translated to 10.30.0.100 and destination to 10.20.20.100 (Inside_Zone)

Now don't ask me why, its an application that cannot be changed, this configuration is a product of a dual layer checkpoint firewall architecture they had years ago, i can't change the way the app works, this unfortunately is the requirement at migration time.

The Question

The question is about NAT Rule position, and about what matches in a NAT Rule, because, if i have this rule in the number 1 position as per below....everything works, if i move it to position 2, it does not......why

Thanks so much for your help, if you need anything clarified let me know and ill provide.

Re: FTD NAT Matching

Francesco Molino — Fri, 21 Jun 2019 03:47:33 GMT

Hi

Can you move back your role at the position where it doesn't work and
Can you ssh your ftd and share in a text file the output of below commands please:

- show run nat
- packet-tracer input DMZ_Zone icmp 172.16.1.100 8 0 172.16.1.200

Re: FTD NAT Matching

Warren Sullivan - Corp — Sat, 22 Jun 2019 01:53:06 GMT

Hi Francesco,

Thanks heaps for the help!

I did both commands the the rule in position 1 (successful) and 2 (Unsuccessful)

See attached;

Re: FTD NAT Matching

Francesco Molino — Mon, 24 Jun 2019 04:01:38 GMT

When you moved your role into position 2, did you clear your xlate table? We can see the asa is doing a route lookup directly on going through the whole process.

I also see you have the same nat but inverted with source from inside. Can you deactivate you nat (dmz,inside) and test only with nat(inside,dmz) by keeping it at the latest position as it's now?

Re: FTD NAT Matching

Warren Sullivan - Corp — Fri, 28 Jun 2019 02:08:15 GMT

Hi Francesco,

No i did not clear the xlate table, this is all done in the GUI, not command line.

Disabling the below rule as you suggested seems to have fixed the issue, yay!

I suppose my question is now....why? this (now disabled) rule published the 192.168.114.200 address on the outside interface and allowed me to access the webserver running on 172.16.1.100 from the outside.

Thoughts?

Once again, i truly appreciate the help you are giving me, its a big knowledge shift from other vendors to Cisco for NGFW.

Re: FTD NAT Matching

Francesco Molino — Fri, 28 Jun 2019 21:46:49 GMT

I suggested another nat not this one.
First, this nat you disabled to expose a server from the outside, should not be put at the first position. Order is important and I would have put it at the latest position.
Now this one is doing nat from DMZ to Outside and you're issue is from DMZ and Inside. Even on the packet-capture it's not being hit.

Can you do a packet tracer like last time once this rule is disabled?
What version of FMC are you running?

Re: FTD NAT Matching

Warren Sullivan - Corp — Tue, 09 Jul 2019 05:11:07 GMT

Hi Francesco,

Please find attached.

using FMC and FTD version 6.4.0

Re: FTD NAT Matching

Ilkin — Tue, 09 Jul 2019 06:34:53 GMT

When NAT rule "nat (DMZ,Outside) source static HOST_172.16.1.100 HOST_192.168.114.200" is in the first position, FTD is doing source translation 172.16.1.100 >192.168.114.200 and using Outside interface as the egress interface based on route-lookup.

When you use the NAT rule "nat (DMZ,Inside) source static HOST_172.16.1.100 HOST_10.30.0.100 destination static HOST_172.16.1.200 HOST_10.20.20.100", FTD is performing twice NAT - 172.16.1.100 to itself and 10.30.0.100 to 10.20.20.100. Since there is a destination NAT involved, the egress interface is taken from NAT, i.e. inside interface in this case, and routing table is not consulted for egress interface determination:

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Inside) source static HOST_172.16.1.100 HOST_10.30.0.100 destination static HOST_172.16.1.200 HOST_10.20.20.100
Additional Information:
NAT divert to egress interface Inside <----------------Here.
Untranslate 172.16.1.200/0 to 10.20.20.100/0