I've just answered a similar question at https://supportforums.cisco.com/discussion/12102421/nat-hairpinning, let me repeat the answer here:
First of all, such a situation is encountered often enough.
Second, while NAT theoretically may be a solution, in practice particular vendor implementations of NAT can be restrictive and fail to support this.
One typical solution is to address the server located in the internal network by FQDN, not by the IP address. Two DNS zones are needed - one external, mapping server.example.org to the publicly known IP, and an internal, mapping the same FQDN to the private IP address of the server.
Up to this point, looks like a summary of others' comments. But here you have something fresh:
If this solution seems unacceptable, there is another one, it avoids NAT too, all that you need is to configure the TCP/IP stack on the server and the LAN hosts. Do this:
(1) on the server: add public IP address (18.104.22.168 in your case) as a secondary IP address on the server's network interface with the 255.255.255.255 mask (web service or whatever you want on the server should listen on this IP address too)
(2) on LAN computers: add a host route for that public IP address, for example, for Windows hosts use the following command: route add 22.214.171.124 mask 255.255.255.255 192.168.1.134 (you can also use DHCP "static route" option to distribute the route). Or, if there is a L3 switch/router in between the clients and the Internet-facing router, configure that host route on this intermediate switch/router, not on the clients.