Public ip address can't be used locally to access hosted websites

Question

I have snow leopard server and I have successfully set up the server to be accessible via a public static ip address. Im hosting some test websites, and cannot access those sites locally using the public ip address, only using the private ip address. However, externally, I can access the sites using the public ip address.
In other words, while I'm at the office, I can only view the sites using the private ip address and not the public ip address. However, while I'm at home I can see the sites using the public ip address.
Why can't I access the public ip address locally?
I'm new to os x server ... New to any kind of server for that matter, so please keep explanations simple.
I'm at a serviced office, and the router here is not mine and I have no control over it. Some IT company manages it for the site, and they weren't very helpful. The basically told me there's nothing they can do and blamed Mac os x server - since they could just wash their hands of the matter since they don't deal with macs.
I was told by someone else, that this is common issue with some routers and that they could fix the issue on their end, but don't want to do it for what ever reason.
I could simply access the sites using the private ip address, but I'd rather use the public one as this is currently causing issues with some of the software we're using.
Any ideas how to resolve this?

Answer 1

The IT company (shock, horror) apparently doesn't understand IP routing, or didn't understand what you were asking. This case has nothing to do with Mac OS X nor Mac OS X Server, and everything to do with the capabilities of the gateway box.
I'm here going to refer to the firewall / gateway / router / DHCP server / box at the edge of your network as a gateway, because I really don't want to type all that stuff each time I describe this box. Your particular box might or might not be capable of all that.
Why? Likely because your particular gateway device is not capable of detecting and reflecting the connections back toward the target server.
IP routing. In small words.
If an IP address is within a range of IP addresses designated by the subnet mask, the packet goes directly to the target host.
If an IP address is not within that range, the packet is sent to the gateway.
The gateway will then send the packet to the next router on the way to the target. With a typical low cost firewall gateway box, that next router is likely the ISP's routers. With a somewhat higher-end box and with a smarter router within the gateway, the packets can go to other IP routers.
If the gateway is implemented for it, the gateway router's own address(es) will be recognized, and reflected back inwards. That means the address is public IP address on the way out, and is NAT'd when reflected, and sent back at the target host via whatever local processing rules or local port-forwarding rules might be defined and present within the gateway box.
Now what usually happens here ([once you get the hang of setting up DNS services|http://labs.hoffmanlabs.com/node/1436]) is called split-horizon DNS, and that's where your public DNS domain is also mostly-duplicated as one of the domains on your LAN and thus reachable in your LAN domain, and your local DNS server in your Mac OS X Server is then configured to return a private IP address (and one within the range of addresses defined by your IP subnet mask), and which entirely bypasses your gateway and allows the packet to go directly to the target box. Put another way, with split-horizon DNS, you insinuate your LAN DNS server into the network and configure it to pass out (or spoof) IP name-to-address translations for your public DNS names, and pass out local (direct, LAN, private) IP addresses.
The other option is to see if the IT company can switch the gateway box into what's usually called "bridged" mode, or swap in a box that acts as a bridge and not a router, and to install your own gateway behind it. Not all boxes permit that, but some do.