Firepower - hairpin/reflected NAT rule

[Micccc4]

Hi Everyone,

On the FTD 2110 running the newest recommended software (6.6.5-81) we have to interfaces on the inside (internal + dmz) and outside one. In dmz there is a service that is exposed to the internet (NAT to the public IP that is with the same network as outside interface). That service in dmz is to be reached from the internal zone via internet. So the expected flow is:

client in internal zone -> source NATed to public IP of the outside interface -> accessing service from dmz zone from internet.

Unfortunately this doesn't seem to work. So there are 2 questions:

- is it supported on Firepower (I know it was achievable on ASA)

- if not what would be the best workaround

Please see attached flow diagram.

All you comments are much appreciated - thanks!

[Rob Ingram · Accepted solution]

@Micccc4 very little information on this scenario, this post is the closest you may find - just amend the destination interface.

[Marius Gunnerud]

Are you also trying to NAT the Internal IP to the outside interface public IP when going to the dmz?  Or are you just trying to reach the dmz using a FQDN that resolves to the public IP?

Are you managing the FTD using FMC or FDM?

[Micccc4]

Thanks a lot for your comments Guys. 

@Rob Ingram - we are going to test shared setup tomorrow or Wednesday and report the status.

@Marius Gunnerud  - end point in the internal zone is learning target's public IP (168.22.22.22) via lookup to public DNS. Then it's initiating the session to that IP. With current setup the idee was that this request will be source NATed to the IP of the Outside interface (168.22.22.10) and then routed to the DMZ service on 168.22.22.22 (inbound static NAT rule).  Firepower capture shows those request on internal interface and it looks like is stops there  

I will keep you updated!

[Marius Gunnerud · Accepted solution]

I do not believe this setup will not work as you are expecting it to work. 

The problem is that you will be NATing the source to the Outside interface public IP.  To NAT to an interface IP the destination interface would need to be the Outside interface, in your scenario the destination interface would be the DMZ interface.  Also, the FTD will drop any traffic to an interface IP that is not the ingress interface IP.  So you would need to use a different IP than the Outside public IP (for example 168.22.22.11).

So your NAT statement should look like the following:

Source interface Inside

Source IP NAT to 168.22.22.11

Destination interface DMZ

Destination IP (162.22.22.22) NAT to real IP of DMZ service

Another option would be to use DNS re-write.  This is where the FTD "re-writes" the DNS reply to the real IP of the DMZ service.  This would require firewall openings on the internal interface towards the private IP of the DMZ service.

There are other option also, such as placing a router in the Outside interface zone to perform hairpin routing and perhaps som NAT, but doing this makes the setup quite....dirty....So I do not suggest doing that.

[Micccc4]

@Rob Ingram , @Marius Gunnerud - thanks again for your responses in this ticket. We were prepared to test all possible solutions listed in this ticket but it actually worked fine with the first one (one from post shared by @Rob Ingram). At first it did not work for the reason you have point @Marius Gunnerud but then we have moved that specific NAT rule over the existing Dynamic Rule (which was NATing all outbound traffic to the Outside interface public IP). Thanks again. Case closed!