cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2190
Views
20
Helpful
7
Replies

FTD NAT Matching

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-Order.jpg

NAT Rule

21-06-2019 12-58-22 PM.jpg21-06-2019 12-58-55 PM.jpg

ACP Rule21-06-2019 1-00-11 PM.jpg

 

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

21-06-2019 1-07-44 PM.jpg

 

 

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

 

 

1 Accepted Solution

Accepted Solutions

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

View solution in original post

7 Replies 7

Francesco Molino
VIP Alumni
VIP Alumni
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


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

Thanks heaps for the help!

 

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

 

See attached;

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?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

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!

 

28-06-2019 12-03-12 PM.jpg

 

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.

 

 

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?

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hi Francesco,

 

Please find attached.

 

using FMC and FTD version 6.4.0

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: