Although 1138's answer is correct, I just wanted to toss in a detailed explanation about what "hairpin NAT" is, how it works, and why it's necessary in this circumstance. If you don't care about the nitty gritty details of IP, NAT and routing, please feel free to ignore the rest of my (rather lengthy) answer.
Without hairpinning, here is what happens during an HTTP connection attempt from a local LAN client (192.168.0.5) to the webserver via the external IP address (207.40.123.45):
192.168.0.5 sends its SYN packet to 207.40.123.45, port 80. Since 207.40.123.45 is not on the local network, this packet is sent to the default gateway (i.e. the router).
The router, which is configured to forward 207.40.123.45:80 to 192.168.0.120:80, rewrites the packet's destination address to 192.168.0.120, and then delivers the packet to the webserver.
The webserver receives the SYN packet, and sends a reply SYN-ACK packet back to the sender's address, which is 192.168.0.5. Since 192.168.0.5 is on the same network, the webserver delivers the packet directly to 192.168.0.5.
The SYN-ACK packet from 192.168.0.120 arrives at 192.168.0.5, but the host there was not expecting a SYN-ACK from 192.168.0.120, and so it is dropped/rejected. The host at 192.168.0.5 continues to wait for a reply SYN-ACK from 207.40.123.45, but of course, that packet will never arrive. The connection attempt will eventually timeout, perhaps after a few retries, and ultimately, the client and the webserver fail to establish a connection.
This problem can be solved by the router at step 2, by applying a "hairpin NAT". In short, the solution is to trick the client and webserver to send their mutual traffic through the router. This is cleverly accomplished by applying a second phase of NAT at step 2, in addition to the one phase normally applied for port forwarding. Here is the sequence again, this time with the added hairpinning NAT:
As before, 192.168.0.5 sends its SYN packet destined for 207.40.123.45, port 80, to the router.
As before, the router receives the SYN packet, and, as per its configured port-forwarding rule, it rewrites the destination address to 192.168.0.120. This time, however, the router notices that it is about to "hairpin" the packet back out onto the same network from which it was received, so it also rewrites the packet's source address to the router's own LAN address (say: 192.168.0.1). The router then delivers the packet to the webserver at 192.168.0.120.
The webserver receives the SYN packet, and sends its reply SYN-ACK packet back to the sender's address, which, this time, is 192.168.0.1. Thus, the reply goes back to the router.
The router receives the SYN-ACK from the webserver, and recognizes that it is a reply to a packet that it recently NAT-ed (twice). So the router dutifully reverses both NATs, and the reply packet now has source address 207.40.123.45 and destination address 192.168.0.5. Hence, the reply is delivered to 192.168.0.5, the TCP connection handshake continues, and the client and webserver are able to successfully communicate.
Thus, with hairpinning support in the router, the host at 192.168.0.5 thinks it's talking to a webserver at 207.40.123.45, while the webserver at 192.168.0.120 thinks it's talking to a client on the router itself (192.168.0.1). When hairpinning, all traffic between the two hosts passes through the router, even though both hosts are actually on the same network. This is obviously a suboptimal use of network resources, and is the main reason why setting up a split DNS is usually preferrable to relying on hairpinning.