1

So we have a website at work that no one inside the work LAN can use. Our customers can use it. I can use it if my phone is on LTE. I can't use it on WiFi, through an ethernet connection at work, or on the DNS server. The portion that isn't working is JavaScript, if that helps.

as an edit: it's a website we own.

  • If you access it by its LAN name/IP from within the LAN does it work? – techie007 May 06 '15 at 19:19
  • 1
    More information needed: 1) Is it browser dependent? 2) Are there referrals *outside the main web site* that might be blocked? Are different names used in the JS for the web site that resolve to the same IP (in which case it might be a DNS look-up issue)? View the source and note every HTTP string, and test access to those separately. You could test on one machine by modifying the *hosts* file. –  May 06 '15 at 19:28
  • @Ƭᴇcʜιᴇ007 It's a website we own, but it's hosted offsite. We can't access it by IP for some reason. –  May 06 '15 at 19:40
  • @DrMoishePippik 1) It's not browser dependent. It happens on IE, Chrome, Firefox, iPhone, and Android. 2) What should I modify the hosts file to be? Would it help if you knew the site? –  May 06 '15 at 19:40
  • 1
    If an office has developers in it, you'll often see search domains being applied that will allow them to access their various dev environments via url, which can affect how the application operates. You may also be getting blocked by the host for some reason. Can you access the site via IP address? http:/// Put a ticket in requesting that they very port 80 and 443 are open to whatever your office external IP is. Visit icanhazip.com to verify. If you have a network engineer on staff, you should take it up with them also. –  May 06 '15 at 20:11
  • If you add to the *hosts* the IP address and the site name, that can test DNS resolution issues. As @alex atkinson suggests, this should be done by the IT department. –  May 06 '15 at 23:14

1 Answers1

1

Without significantly more information, it is very hard to draw any accurate conclusion as to why this would occur. One issue I frequently see on particularly small-mid sized business networks has very similar symptoms; you can access services hosted internally from an external location, but you can't access them internally. This is different from your scenario as you clearly stated that the services are externally hosted, however there may be a component internally hosted which you haven't considered.

To summarise what happens: A client makes a request to a domain name, which resolves to your networks external IP address. The client's request then reaches your external address, your router translates this request using your NAT/PAT rules and determines "You want to talk to this server", and forwards the request. The server responds, and your router forwards the response back to the client.

When you access this same name from an internal client, it still resolves to the external IP address of your network, however when you make a request your router says "whoa, you are already INSIDE the network, I don't need to do any work", because a router facilitates communication "between" networks.

Most cheap routers implement a feature called 'Reverse NAT' to deal with this, and it is not something you can typically control, hence why it rarely effects small businesses and enthusiasts. Larger organisations generally have the proper DNS and Routing infrastructure in place to handle these scenarios, and their architecture is generally thought out. Unfortunately most mid sized businesses fall into limbo, where they need the flexibility of higher-end hardware, but don't organise or configure their installation adequately.

Firstly, you need to identify if this is what is happening.

  1. Tether your phone to your computer, and go to the website in your favourite browser.
  2. Observe that everything is working. Open the browsers developer tools and locate the network request/response section. In Internet explorer you arrive there by pressing F12 and opening the Network tab.
  3. Start recording traffic by pressing the play/record button, and reload the page.
  4. Invoke something javascript based that doesn't normally work within your network.
  5. Stop the capture.

Now review the list of network requests made and write down all domain names from these requests. Query their IP addresses using nslookup. If one of these is your private network's external address, this will probably be your problem. If this is the case, simply amend your internal DNS server to resolve this address to the same node which your router forwards this traffic to.

If you are adamant that your website is entirely self contained on the external host, sanity check that your browsers security settings are not just affecting javascript within your organisation. The easiest way is to connect the same PC you use internally to the internet directly via your phone or another device, and verify everything works as expected.

nslookup command line usage: nslookup hostname.com 8.8.8.8, where 'hostname.com' is the name you want to resolve, and '8.8.8.8' is a commonly used public DNS server. If no DNS server is specified, it will use your computers default.

Élie
  • 146
  • 3