Redirect outbound traffic to external ip to local ip


I have a multi-office network where the remote offices are connected by VPN tunnels to the main location and all share the same internal DNS server.  I have a public web server that sits in a DMZ reachable by the public and remote offices via a dedicated public IP and is reachable by internal users of the main location via an internal IP.  The firewall controlling all of this is a Cisco ASA 5505.

Everything works and routes well by IP except one thing.  In the main office where the firewall is located (where the servers and dmz are) those users cannot reach the public IP of the web service.  They can get to it using the internal address, but not by the public address.  All other offices can get to the public IP just fine.

Except for the shared DNS between offices, I would just set up an internal host address that pointed to the inside address for this one office.  But the other offices would then pick that up and they don't get to the website via the internal address.

What I need is for the firewall, which is handling the requests anyway, to "rewrite" the destination for main office users to the DMZ address reachable from the main office.  So Main Office machine x.x.x.105 sends a request to y.y.y.149 (the public web server address) and it needs to go to z.z.z.20 (the internal DMZ address of the web server).

The DMZ machine has no problem reaching the x.x.x network.  I just need to inform the firewall that requests going to y.y.y.149 should not be NATed and should go instead to z.z.z.20.

How do I do this?
Who is Participating?
The default behavior of an ASA is not allow traffic originating from interface a to come back on itself.

What your Main office setup is

When a user on the LAN wants to access the WAN IP port 80

The traffic goes from computer to ASA Inside to ASA Outside and then tries to comeback through the ASA outside and be directed to the DMZ -> system/port.

The issue is not with the security on the interfaces which will be enforced accordingly
The issue is with the path a packet is taking.

Lets say you ask your subordinate to go to  the office of another manager.
The subordinate does not know/have information on where the office is such that the subordinate must go to the lobby to look at the office directory.
The subordinate leaves your office, walks out the front door looks at the directory and then reenters through the front door on the way to the office of the other manager.

Without the same-security-traffic permit intra-interface
The individual will not be allowed back in.

This is often an issue one wants to prevent.
The use of this is primarily to deal with spoof packets.

I.e. an http packet is sent to your web server with the source/port as the wan IP/80.
The issue would start a loop where your DMZ web server will then try to negotiate with itself a TCP.

If you use the same domain name for your AD and the public
The DNS solution is fine since your locations are interconnected, the systems will be able to locate the internal IP of the web server without having to go through the external DNS.

I.e. branch offices instead of using the external public IP will be going through the site to site VPN to the internal IP.

if you use separate (local/private) for AD and public.

You would need to maintain two copies of zones for the public domain name.

Ernie BeekExpertCommented:
There are ways to do that,for example:
Have a look to see if that helps you.
OuttaCyTEAuthor Commented:
Thanks for that reference!

I think one of the items might do it, but I find creating the Nat entries confusing so I'm going to pass it by y'all.

From the reference: static (real_interface,mapped_interface) mapped_ip  real_ip

The inside network is named "Inside", the DMZ network is "DMZ" and outside is "Outside".

For my purpose, a machine on the inside needing to get to a machine on the DMZ with an address that would otherwise be outside, which interface is real and which is mapped?

Would it be: static (outside,DMZ) z.z.z.20 y.y.y.149 ?

I get in a knot everytime I try to deal with NAT as it's bass-akwards from my way of thinking.

WEBINAR: 10 Easy Ways to Lose a Password

Join us on June 27th at 8 am PDT to learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees. We'll cover the importance of multi-factor authentication and how these solutions can better protect your business!

Ernie BeekExpertCommented:
Have a look at: that might explain it better (thx to kvistofta :)
OuttaCyTEAuthor Commented:

That really looks like a match.  I'm going to give it a try tonight/tomorrow night.

Ernie BeekExpertCommented:
Let me know how it works out.
I think what you are looking for can be accomplished by DNS doctoring using the "ALIAS" command on the ASA.

alias (inside)
OuttaCyTEAuthor Commented:
@dslam24,  The problem with Alias and Static NAT with DSN fixup is that the DNS is not external.  It's internal.  It services all of our offices.  All of the offices, except the main office, need the ip returned by the DNS.  It's only the main office that is having the issue.

@erniebeek, We were attempting to put in the Static Nat but since we already have a static nat to that machine from Outside to the IP in the DMZ, we can't also place one from Inside to the same IP in the DMZ.  We think the solution will be to give the NIC another IP, also in the DMZ and then Static Nat to that.  We haven't actually tried it yet due to scheduling conflicts.

OuttaCyTEAuthor Commented:
We are going to get this in tomorrow or Friday most likely.  Sorry for the delay.
Ernie BeekExpertCommented:
No problem, we'll be here :)
OuttaCyTEAuthor Commented:
Dratted plan changes.

We no longer have the original situation, but I'm still going to test it out.  There is also another variant that has possibilities to solve the original problem as well so I'm going to try that out as well.

I'll report back, but it won't be until after Thanksgiving probably.  We are doing an exchange conversion and that will take out the rest of this week and the weekend.

My investigating is second seat to paid work unfortunately... :)

OuttaCyTEAuthor Commented:
I just tried the original idea with the static nat.  Unfortunately it did not work.
I placed it in the DMZ section and specified z.z.z.30 as the "source" and the translated area I put the y.y.y.149 specifying the inside interface.

I tested with the Packet Tracer.
Interface Inside, Type TCP, Source x.x.x.100, Dest y.y.y.149, Port 80 on both.

I get green checkmark on Flow-Lookup, Un-Nat, IP-Options, and on the first NAT-EXEMPT
and a red check on the second NAT-Exempt.

The first Nat Exempt shows what I was expecting.
   Type NAT-EXEMPT, Action - Allow
   match ip inside XX-network DMZ z.z.z.0
   NAT Exempt
   translate_hits = #####, untranslate_hits = #####

The second Nat Exempt shows:
   Type NAT-EXEMPT, Subtype - rpf-check, Action DROP
and nothing else besides the red X

I'm wondering if I placed the Static Nat statement in the wrong place?

The first Nat Exempt rule is in the DMZ area and applies to traffic within the XX-Network going to the DMZ.

I'm not sure what the second is.

I don't see anywhere where the NAT is picking up on the y.y.y.149 and attempting a re-direct to z.z.z.30

I've got another odd Exempt statement in the inside with the source listed as DMZ and Dest of any.  This looks like it should be there.  I'll delete it tonight after hours  (Sure wish I could turn off NAT rules like I turn off Policy rules.

The issue is that your router ASA does not allow traffic leaving an interface to come back in which is what preventing your internal users from accessing an external IP at the main location.

same-security-traffic permit inter-interface #will likely solve this
same-security-traffic permit intra-interface #might be needed for the NAT options you were trying.

The two options and their differences
OuttaCyTEAuthor Commented:
Hi Arnold,  thank you for the reply.  I've worded the response generically to not exclude others from replying as well.

I'm trying to understand Arnold's response.  I googled for those options and read up on them.  Here is some more info that may be relevant and hoping for expansion on the information.

For what it's worth, it seems that Cisco has been doing some work in this area and the various versions of the software make a difference.  I'm using 7.2(4) and note that 8.3 has a new NAT command structure which makes me wonder if the new version would help... .

I didn't mention security levels so far so to clarify:  The traffic is originating on inside x.x.x.0 (security level 100) and going to the DMZ z.z.z.0 (security level 50).  The outside is security level 0.  All three of my subnets are at different security levels and are plugged into different ports on the ASA.  

I do not see this layout meeting the INTER-interface criteria and do not see why it might solve the problem.  All of the subnets are at different security levels.  Why might the INTER-interface option solve the problem?  I'm game to try it, but seeking some additional information.

However, it had not occurred to me that this might be a variant of hairpinning, thus INTRA-interface.  At first glance, the inside traffic going to y.y.y.149 goes out the inside interface and goes in the DMZ interface and is not the same interface.

On thinking about it, it may be that the flow isn't as simple as the first glance.  Perhaps it is IN to the Inside, OUT to the outside and then the outside interface having to re-inject IN the outside (come back into, thus hairpin) and OUT to the DMZ?  The middle piece might be a hairpin, if the ASA is doing it this way.

The above conjecture doesn't seem to fit observations however.  On my last comment, I noted the NAT-EXEMPT and it shows that it no-natted correctly with no mention of the y.y.y.149 at all, apparently before that it had resolved y.y.y.149->z.z.z.30 (which I found strange).  There was no information that even suggested that the traffic got to the outside interface.

The second NAT-EXEMPT is what failed.  What is a Subtype of rpf-check?

Looking for more understanding as why these options might be the solution

OuttaCyTEAuthor Commented:
Thanks Arnold

I'll give this a try and see what happens.  I appreciate the explanation.

OuttaCyTEAuthor Commented:
Arnold had the most complete explanation and since it appears I'm having trouble getting to this, I'm going to accept.  We have a work-around in place (Which I don't like, but that's life) so we're going to stick with it until I get a chance to re-do the network.

Thanks all,
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.