IP Networking

We cannot access our local servers from our LAN, but we CAN access them from everywhere else!

Every once in awhile, our local access to our servers drops, but if I SSH into an external Linux account I have, I can then SSH back into the server right in the next room. We've been trying to deal with this for months, and our internet provider is investigating.

SSH access through the server is fine for command line access, but how can I set up a PROXY to get graphical WEB BROWSER access through that machine to a graphical app on our local server?

We're dead in the water without it.

You're saying that every once in a while you cannot access machines across your own LAN? But it works most of the time?

When you are trying to make a local connection what utility/command are you using? What network protocol? And when the connection fails, what error does it give?

I understand your point that remote inbound access still works whilst this problem is going on.

---------- Post updated at 09:08 PM ---------- Previous update was at 09:05 PM ----------

When local connections are failing are you using the nodename or the target ip address in the command?

---------- Post updated at 09:09 PM ---------- Previous update was at 09:08 PM ----------

Oh, and can you please tell us all what O/S's we are talking about here.

We have a bank of static IPs we purchased from Comcast, and we have been dealing with loss of access for a long time and applying all sorts of bandaids, from new routers to having a tech come in to resetting equipment. Access is a problem with all protocols -- http, https, ssh, sftp, tcp -- and the failure is a timeout. There is apparently some routing algorithm being used that gets lost somehow, through all configurations of equipment we have. All eight servers are affected. Just those IPs, and just internally, and just intermittently. Aggravating. So until it gets solved, we need to have a workaround for, in this particular case, http, since we have a workaround for ssh/sftp.

---------- Post updated at 03:14 PM ---------- Previous update was at 03:10 PM ----------

We use both IPs and the domain/URL. All are affected. The machines attempting to access it are Mac OS X, Windows and Linux, several of each, and they all encounter the same timeout. The "hairpin" through the other server works fine for ssh and sftp, but not http for our graphic apps.

So your local servers are using the bank of purchased static ip's and are effectively directly on the internet?

If when trying to connect locally you are referencing a nodename, then that nodename will need to be resolved to an ip address. If your DNS service is external (and unreliable and perhaps provided by your ISP) then if it becomes unreachable every so often it would affect your local connectivity too. Just a thought at this early stage.

Do you know where your local nodes get their DNS settings from? Are they acquired through DHCP?

If the timeout is caused by DNS failure then setting local resolution through /etc/hosts file entries might help.

What O/S's are we talking about here?

---------- Post updated at 09:30 PM ---------- Previous update was at 09:21 PM ----------

Stating the obvious, LAN connections do not need any ISP or WAN involvement once the connection is established.

I may well be wrong but my experience would tell me to look at the DNS service reliability and/or the actual DNS settings and where they are acquired. This type of timeout connection issue bears all the hallmarks of a DNS screw up.

Let's hope we soon get other input from other forum members. There's probably questions that I've forgotten to ask.

---------- Post updated at 09:35 PM ---------- Previous update was at 09:30 PM ----------

You could configure another system on your LAN as an internet proxy server if you believe for some reason that it won't suffer the same issue. You'd then need to configure all your workstations to use that proxy (or autodetect that proxy).

---------- Post updated at 09:38 PM ---------- Previous update was at 09:35 PM ----------

You could interrogate your systems to see what primary DNS and secondary DNS server ip addresses they are using. Then set up a couple of machines to ping each of these continuously. See if they are still successfully pinging when the problem occurs or whether the DNS servers are unreachable at that time.

Well, I have to assume Comcast will fix this eventually, so I'm not interested at the moment in solving that problem, only getting a workaround.

It's ONLY a problem for those particular IP addresses.


What I'm interested in now is applying that "hairpin" scheme I'm using for ssh/sftp/CLI to solve the issue for web browser access.

I have the resources and the external server -- how do I use them?

---------- Post updated at 07:37 PM ---------- Previous update was at 04:31 PM ----------

Well, again -- this is just a workaround. It occurs to us that regardless of whether this problem is fixed or not, we should have a workaround like this in case something similar happens in the future.

Essentially what we're looking for is a sort of "man in the middle" arrangement, so as to minimize the user's requirement to be aware of it.

We'd like to install something on our proxy that simply forwards the http traffic packets that should go from A to C and can't, and just sends A to B to C and then C to B to A. I suppose there's some technical name for that, but that's the pretty simple idea.

Is there a software app that does that? Is that just the definition of a "proxy"?

It is very difficult for me to provide meaningful answers without knowing the full topology of your network; whether your servers are indeed using static internet addresses, and how your client workstations access the internet - switches (managed or unmanaged, firewall(s), internet router (and how it's configured), etc. Perhaps you could have a go at describing that to us all. Are the clients on a different ip domain (class c address) than the servers?

As far as your question regarding a proxy for http traffic (man-in-the-middle) there are hundreds of publically usable proxies out there (principally used to prevent tracking). These exist on every continent of the planet and many are reliable, many are not reliable.

Search Google for "free proxy list".

For http traffic you could test one of your Windows clients by setting the IE connection to "use proxy server" and configuring the ip address of your chosen proxy. See if that works reliably. If not, pick another proxy.

So you're saying that it's not possible to use the server I'm currently using for SSH/CLI access to do something similar for HTTP? Or far more complicated?