This post basically describes the technique of how to deal with traffic originating from the inside of a firewall, and directing the traffic over the external interface IP address to a different internal zone.

First a network overview of the things used in this setup. The firewall (a Juniper SRX100H) has the following ' security' zones (as shown in the following figure):

Internet
Guest
DMZ
Internal

Access to the Internet (from the Guest and Internal network) is provided by a basic source NAT configuration, and the interfaces are configured with the following IP addresses:

fe-0/0: 10.10.10.1 (physical), 10.10.10.2 (proxy ARP)
fe-0/1: 1.1.1.254
fe-0/2: 2.2.2.254
fe-0/3: 3.3.3.254

The challenge is the following;

We have a web server (WWW) in the DMZ. This web server is accessible from the Internet by entering WWW in the browser, and the DNS server (8.8.8.8) resolves this to 10.10.10.2. This address has a static NAT configuration to the IP address 2.2.2.2.

If someone on the Internal network wants to access the WWW server, the internal DNS server resolves WWW to 2.2.2.2. On both occasions, the user can access the WWW server.

Now we have a zone where we place untrusted guests. These guest will have basic Internet access, but also might need access to the WWW server in the DMZ. This might be a problem.

First, when we use the public DNS (8.8.8.8) for resolving the WWW server, we get the external IP address (10.10.10.2). Many firewalls can't deal with this, since the traffic is originating on the inside, needs to access the public IP, and after that 're-routed' to configured the static address (10.10.10.2 -> 2.2.2.2) on the 'inside'.

Second, if we use the internal DNS (3.3.3.3) for resolving the WWW address, we create a security issue, because the Guests might be able to map the internal network by guessing hostnames and receiving the internal IP addresses.
An alternative solution might be to use a seperate DNS server in the Guest zone. Configure this Guest DNS server with the appropriate zone for resolving the WWW host, and let it be a caching DNS server for the rest of the Internet.
The downside is that you need to administer an additional DNS server. An alternative is to use a distributed DNS environment like e.g. Infoblox/Trinsic appliances, but these are relatively expensive.

The real solution is using the existing static NAT rules (from Internet to DMZ) in the JUNIPER SRX firewall.

The reason that Juniper is displayed in a bold type-font is that from what I heard is that other vendors have problems with this U-turn (redirecting originating inside traffic on the outside interface back inside). Note that I have limitied knowledge on how other firewall function. You may correct me if I'm wrong, and if you do, please support your claim by leaving the solution for the other vendor in the comments.

This NAT rule needs to be altered to allow access from the Guest zone. This makes it possible to use the public DNS (8.8.8.8) for resolving. Which saves you a couple of bucks on additional hardware.

security {
         nat {
             static {
                 rule-set StaticNATS {
                     from zone [ Guest Internet ];
                     rule WWW {
                         description "Public Access WWW";
                         match {
                             destination-address 10.10.10.2/32;
                         }
                         then {
                   static-nat {
                                 prefix {
                                     2.2.2.2/32;
                                 }
                             }
                         }
                     }
             }        
         }            

After this, you need to define a firewall policy from the Guest to the DMZ zone to allow (http, and https) traffic from the Guests to the WWW.

security {
          policies {
                  from-zone Guest to-zone DMZ {
                      policy Guest-to-DMZ {
                          match {
                              source-address Guest-Network;
                              destination-address WWW;
                              application [ junos-http junos-https ];
                          }
                          then {
                              permit;
                              log {
                                  session-init;
                                  session-close;
                              }
                              count;
                          }
                      }
                  }
         }

What happens is the following;

The guest enters the WWW url in the browser
The browser resolves the WWW address to 10.10.10.2 by using the public DNS (8.8.8.8)
An http session is created with the public IP adres (10.10.10.2), but gets translated to the DMZ address 2.2.2.2.

Since there's a security policy that enables traffic from Guest to the WWW server in the DMZ, the communication between the two hosts is allowed.

If you're analyzing the security session table (show security flow session) on the CLI, you might see something strange:

Session ID: 5694, Policy name: Guest-to-DMZ/5, Timeout: 1762, Valid
  In: 1.1.1.1/49201 --> 10.10.10.2/80;tcp, If: fe-0/0/1.0, Pkts: 145, Bytes: 24184
  Out: 2.2.2.2./80 --> 1.1.1.1/3707;tcp, If: fe-0/0/2.0, Pkts: 144, Bytes: 20425

You'll see that you're missing a piece of the communication (10.10.10.2 -> 2.2.2.2). This is due to the NAT part in this solution. The J-Web interface shows the actual address as well, by combining the security flow session information and the NAT information.

Public DMZ Access From Within The Network