Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have 10 computers on LAN of which 1 is a server for a web app. All the 9 computers can connect to the server for work. Now we got a broadband internet connection in another computer and shared it with the others for accessing an app over VPN. Now we could not connect to the local servers web app. What may be the problem and its probable solutions ?


share|improve this question

closed as not a real question by RobM, pauska, kce, HopelessN00b, Iain Oct 6 '12 at 14:40

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Pretend that none of us can see your computers from here, and explain a little bit about the topology of this LAN, IP address ranges, what you've tried already to troubleshoot this, etc. –  RobM Oct 4 '12 at 7:05
Also, saying "we could not connect" is not a helpful problem description. How far did you get? What was the first step that didn't work? What error did you get? –  David Schwartz Oct 4 '12 at 7:16
We were not able to access the local server app whereas we can access vpn over broadband. –  0xFaCeB00c Oct 4 '12 at 7:19
We were not able to access the local server app - so again, what happens when you try? When you post here you're asking people to help you, for free, with a problem you're having. When you don't post details and make people play '20 questions' to get the details from you, you're being disrespectful to the people you want help from, and they're likely to respond by ignoring your question in favour of helping those who make it easy to help them. –  RobM Oct 4 '12 at 7:34

1 Answer 1

For web app troubleshooting, you need to check each step individually. This means using dig to check the DNS request, curl and tcpdump (on both client and server) to check the TCP connection, strace to check what the app does when it gets the request. You should stop whenever you get the first unexpected behaviour

You also need to understand (and add to your question) the difference between (for example) a timeout at the DNS request stage compared to a response with an incorrect answer such as NXDOMAIN or the wrong IP address.

If your nameserver returns the wrong answer you will probably get a timeout when trying to connect to the IP address but if the IP address is active on the network and its firewall isn't dropping packets then you will get a RST packet back instantly. The difference between these is important.

If you are getting timeouts at the TCP connect stage, it can be due to the client's outbound firewall rules, the server's inbound rules, the server's outbound rules or the client's inbound rules. Running tcpdump on both client and server and looking at the firewall logs will help you distinguish between these cases.

If you manage to connect and send a request but your web app is doing something that takes a long time and hence never sends a response, you will get yet another timeout. You might even get a RST packet at this stage.

The difference between a timeout at the DNS stage, a timeout at the TCP connect stage and a timeout after the HTTP request has been sent is an important first step. It narrows down where the problem could be, it may even tell you exactly what the problem is.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.