General Networking/Lan/Wan/WAN Clients computers unable to access Apache server using WAN IP
abit of background
* i have got MPLS WAN solution with an Apache webserver at HQ.
*router at HQ 1941
* private IP scheme at HQ is 192.168.1.x
* i can browse the apache server from the internet
* computers in the LAN at HQ can browse the Apache server using the LAN IP or the FQDN of the server box
* the Clients in the other sites (10 of them ) can only browse the apache server using the LAN IP Address (of the server box at HQ)
so what is my challenge?
well i have several applications one of which is the ICT service desk and an intranet which i would like the users to access using one single URL , the FQDN of the server. This is becoming a challenge given the problem with the site offices.
could you please point me in the right direction ?
thank you in advance.
ANSWER: Hi Sam,
Well it seems to be either a DNS issue or a PC/DHCP configuration issue for the PCs across the WAN (well ... or both but usually it's just one or the other). It's time for some trouble-shooting 101. And we need to know more about quite what is working and what isn't working.
I'd first start with doing a "ipconfig /all" on a remote WAN PC - to make sure that you know what their DNS server settings are, and go from there. You'll see stuff like this:
C:\Documents and Settings\Jeff>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : HOSTNAME
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter WIRELESS:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Wireless WiFi Link 4965AGN
Physical Address. . . . . . . . . : 00-1D-E0-66-24-C1
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.110
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
Lease Obtained. . . . . . . . . . : Sunday, May 05, 2013 8:04:49 PM
Lease Expires . . . . . . . . . . : Monday, May 06, 2013 8:04:49 PM
Is the proper DNS server there - the one that has the record of your internal server? If yes, does a ping work properly for the fqdn? probably not ...! But do that and let me know exactly what it says.
I'll hear back from you soon? Thanks!
---------- FOLLOW-UP ----------
QUESTION: Thank you for the prompt reply.
I did(ok someone did for me ) a ipconfig /all on a node at one of the branches and noted that the dns servers are those provided by the ISP. *The DHCP is also the one configured on a cisco 881 router at the branch.
*Those are the same dns servers configured at the HQ router.
*The DNS server box at HQ is configured to use the same ISP DNS servers
* a ping to the external IP address of the router at HQ from the branch node gets replies
*a ping for the FQDN from the node works
* browsing the FQDN in question returns "cannot connect to URL
>> I did(ok someone did for me ) a ipconfig /all on a node at one of the branches and noted that the dns servers are those provided by the ISP. *The DHCP is also the one configured on a cisco 881 router at the branch.
>> *Those are the same dns servers configured at the HQ router.
>> *The DNS server box at HQ is configured to use the same ISP DNS servers
>> * a ping to the external IP address of the router at HQ from the branch node gets replies
>> *a ping for the FQDN from the node works
>> * browsing the FQDN in question returns "cannot connect to URL
Ok ... that is just really weird! If I'm understanding you correctly, all these tests are for a Remote Node / PC located at a branch site - right???
Sigh! That is darn confusing. So it looks like it's got the correct DNS server, and they can even PING the correct server??? But not HTTP to it??? That is just freak'n weird. I would only expect those particular symptoms if the HQ doesn't work too. What I EXPECTED is that the ping would fail - which then leads us to a certain path.
Were I on-site, I could probably figure this thing out but it's actually getting a bit involved to diagnosis it from near Philadelphia :-) At this point, I'd call your ISP up, since they are hosting your DNS for you, and review the specifics - they'll want the bullet points so that they understand exactly what is and isn't working.
At this point it doesn't SEEM like a DNS issue but I still wouldn't rule it out entirely. It also somehow might be a permissions/security thing ... it's hard to know if those packets are actually getting to the Web server from the remote WAN node or not. Bottom line - we need another set of eyes looking at it. Usually I'm pretty good at isolating things like this - and I am sorry that I don't have the answer for you this time.
But I'd really much rather that you get things going than to spend more time without a clear path to keep going for you.
I wish you the best!