Hairrpinning ? Outside to Inside

[manuscript1]

Hi  all

we have a strange problem , not sure if this is hairpinning or just the way an ASA works .( latest os)

WWW users can succesfully target the sftp server external address and hit the reverse proxy and then sftp files to the internal  server. ( using nat on external and rules ) .

However when internal users target the sftp server using the external address things start going astray ,the firewall packet trace suggests that the packet does go from the internal 10.x.x.x address to the  external address...( does it ever ? ).............however how does the return packet get back .......

is this hairpinning ? or something else ? do i need extra xlates in ... I have teh obvious ones in play

Diagram attached

Thanks !!

[Karsten Iwen]

That's the way the ASA works. There are three ways to solve the problem:

1. If your NAT is 1:1 without services, you can add the keyword "dns" to your NAT statement. With that, when the clients try to resolve the IP for your FQDN, the ASA replaces the translated address in the reply with the real IP
2. Configure your internal DNS to return the real IP of the reverse proxy when a client connects to the SFTP-FQDN.
3. configure destination NAT on the inside interface to change the public IP to the IP of the reverse proxy.

This is also the order of options how I would prefer them.

[manuscript1]

I have tried a inside to outside NAT and fails still

I have tried a inside to dmz nat and also fails 

nat is inside to dmz source ANY destination "external ip address" service any source - original(s)  destination" real ip address of server in dmz "

or inside to outside as a test with same parameters

i have supporting rules inside to dmz and inside to outside allow ip any

still no joy !

Cannot do option 2 above - dns does resolve ok however so not dns

[Cristian Nilsson]

Hello,

Question: is there a reason to not point at local ip of sftp server?

//Cristian

[manuscript1]

yes because for some bizarre reason the setup server internally expects from the reverse proxy