CRL ltd
asked on
Cannot access own website internally
I have a client that cannot view their own externally hosted website on most of their PC's and servers when they are internal on the network. The only devices that works are their domain joined Terminal Server and local VM host server. You can ping the web address without any issues from all of the devices and it resolves to the IP address that is in the A record in DNS on the DC.
Their internal domain is {companyname}.local and their website is {company-name}.co.uk. I have completed an NSlookup for www.{company-name}.co.uk and the non-authoritive answer comes back as the IP address of the A record.
They also use CyberDuck to upload documents to the webpage and this cannot connect either. The company recently undertook an email migration from on-site exchange to Office 365 but we cannot confirm whether this may have had any affect..
Their internal domain is {companyname}.local and their website is {company-name}.co.uk. I have completed an NSlookup for www.{company-name}.co.uk and the non-authoritive answer comes back as the IP address of the A record.
They also use CyberDuck to upload documents to the webpage and this cannot connect either. The company recently undertook an email migration from on-site exchange to Office 365 but we cannot confirm whether this may have had any affect..
in your local DNS server, is there a zone for {company-name}.co.uk and an accompanying A record?
ASKER
There is a subtle difference between the internal and external. One is Comanyname.local and the website is www.company-name.co.uk (there's a hyphen in the website).
There is an entry in DNS called company-name.co.uk which has an A record pointing to the external web address.
There is an entry in DNS called company-name.co.uk which has an A record pointing to the external web address.
So in *theory* it should resolve. Can the DNS server ping it properly and resolve the website? Is the terminal server using the correct DNS server?
From what you're describing, everything should work properly (repeat of comment from CES). From any of the machines where you're having issues, could you please show the result of a tracert?
ASKER
The DNS server and all of the PC's with issues can ping the website and resolve it without issues. I've pinged the website from an external source to confirm IP address is correct.
I have completed a tracert on a couple of the machines with issues and it goes all the way to the IP address of the webhost without issues.
I may be wrong, but I can't see it being a DNS issue however I am open to any suggestions
I have completed a tracert on a couple of the machines with issues and it goes all the way to the IP address of the webhost without issues.
I may be wrong, but I can't see it being a DNS issue however I am open to any suggestions
Is there a difference between how your terminal services service accesses the internet versus other systems? Like in web filtering and so on?
ASKER
I've just logged onto both servers and the TS is actually on a different public IP address to the DC and users. Could it be the ISP is blocking access to the website?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You likely hit the problem.
Many ISPs provide both an internal + public IP for all their machines, so routing optimization can be done when machines inside the ISPs infrastructure are communicating with each other. This ensures fastest communications, as packets stay inside local, high speed network fabric.
Simple solution is still as I suggest above, just use a single, public IP for all site access, so no DNS or routing games are required to setup + maintain + debug.
As you've seen, this can create significant time to debug.
Many ISPs provide both an internal + public IP for all their machines, so routing optimization can be done when machines inside the ISPs infrastructure are communicating with each other. This ensures fastest communications, as packets stay inside local, high speed network fabric.
Simple solution is still as I suggest above, just use a single, public IP for all site access, so no DNS or routing games are required to setup + maintain + debug.
As you've seen, this can create significant time to debug.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
No one else has been able to give a solution to the issue and a workaround has been found for it
And, this is generally a bad idea... because...
Simple things like HTTPS will never work with this type of setup, because foo.local will never match the SSL cert.
Simple fix, only reference Websites by their public name.