said by gozer9:I would apreciate if you could test my idea and set up a new DDNS name w/staic ip that is your lans host private IP and set a static route in the modem/router and see if this works.
Well, that would work but wouldn't meet the OP's requirements of using the same hostname for both internal and external. If his service is a web server and his DynDNS service supported DNS round robin (multiple A records), it would work as most modern browsers will automatically move to the next A record if the first doesn't respond. But services like DynDNS don't support multiple A records. Maybe multiple /etc/host entries to get the same?
Along that concept (and not using DNS), you could add the WAN IP of your modem as a secondary IP to the server. Then on the clients you want to access the server using the "WAN IP" address from inside the network, you static route (on the client) the WAN IP to the real LAN IP of the server.
For example, I configured this for my terminal server:
int eth0
ip address 192.168.1.200 255.255.255.0
ip address real.wan.ip 255.255.255.252 secondary (or as a loopback interface)
Then on my PC, I did:
route add -p real.wan.ip mask 255.255.255.255 192.168.1.200
This caused my PC to send all packets for the WAN IP of the modem directly to the terminal server, bypassing the modem. That works fine until I take my laptop with the static route off the private LAN network and somewhere else (say to the coffee shop down the street). Then my connections back home get blackholed if I forget to remove the static route.
I can get around that by forgetting about the static route on the PC entirely, artificially widening the mask (or changing the subnet) on my LAN DHCP pool to be inclusive of the WAN IP, and enabling proxy-arp on my terminal server. That works for me, but I suspect his "server" is not a Cisco router which supports proxy-arp. Also, all of these would be annoying in that I'd have to update the server manually every time my WAN IP changed. Not really a clean solution.
Actually, there is documentation, just none that's externally published and little that's provided to technicians. The modem is supposed to be simple to subscribers. It's the whole "if we supply documentation on how to do other things with it, then our CSRs/techs get roped into supporting those other things." I won't argue if that's really a good business idea or not (I'm pretty sure I can guess where you guys all stand on the matter), but the documentation is intentionally bleak and not all config items are available in the GUI. You are literally on your own to make anything other than the basic config work, if it's even possible to do what you want.