5

I am having difficulty making connections to websites using Firefox over a tunneled SOCKS proxy. SOCKS4/SOCKS5 makes no difference.

I set up the tunnel with

ssh -D 1234 id@remotehost.example.com

then point Firefox's SOCKS proxy to localhost on tcp/1234.

One key point to note here is that the tunnel I am setting up is on a remote server I have been using for this purpose for many years. I have proxied FF and other browsers through it for many thousands of sessions on a dozen or more different platforms across all major OSes. Once I get it working, it always works smoothly. However, on this particular instance of FF, I get odd and intermittent problems.

The problem is that FF doesn't seem to "want" to establish a connection. I type in a URL or click a link and I instantly get "Unable to connect" / "Firefox can't establish a connection to the server at ..." When I say "instantly," I mean this pops back to me in some small fraction of a second.

So I hit "Try again" or the little reload arrow. And I do it again, and again, and again, as rapidly as I can. And after a few tries -- sometimes 3-4, sometimes as many as 15-20 -- I get a connection and everything works! So the tunnel / SOCKS connection is available, it's just that FF refuses to use it until it is bullied into doing so. Once I get a connection, further reloads do not cause it to be lost.

I have some add-ons, but a) I've disabled them selectively with no help, and b) I have (of course) tried safe-mode. There is no change.

Any suggestions?

JD Baldwin
  • 633

2 Answers2

7

I have to use a proxy everyday at work in order to connect to servers on the other side of a firewall. I also use Firefox, Chrome and Ubuntu 16.04.

EDIT: I forgot one part of this. I have had to add a timeout to a ssh config file or my tunnel will timeout and I lose my connection. Once I added the following stuff, my connection stays open:

In ~/.ssh/config add the following information (if the file does not exist, create it.). This will send a server keepalive to your tunnel every 15 seconds.

Host *
ServerAliveInterval 15

I open my tunnel connection with the following command:

ssh -CfND 1234 username@proxyhost

Then in Firefox under the Connection Settings in the Manual proxy configuration I only fill in the SOCKS Host: with 127.0.0.1 and Port: 1234. Then I make sure that SOCKS v5 is selected. Also note that I don't have anything in the No Proxy for: box.

I am able to connect to my hosts that way without any problems.

enter image description here

Then for Chrome I run a command line so I don't have to set the settings to Chrome every time I want to go through the proxy, then no proxy. To connect Chrome to the proxy I run the following line:

nohup google-chrome-stable --proxy-server="socks5://127.0.0.1:1234" & > /dev/null 2>&1

from ssh manpage

 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11, TCP and UNIX-domain connec‐
         tions).  The compression algorithm is the same used by gzip(1),
         and the “level” can be controlled by the CompressionLevel option
         for protocol version 1.  Compression is desirable on modem lines
         and other slow connections, but will only slow down things on
         fast networks.  The default value can be set on a host-by-host
         basis in the configuration files; see the Compression option.

 -f      Requests ssh to go to background just before command execution.
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         implies -n.  The recommended way to start X11 programs at a
         remote site is with something like ssh -f host xterm.

 -N      Do not execute a remote command.  This is useful for just for‐
         warding ports.

 -D [bind_address:]port
         Specifies a local “dynamic” application-level port forwarding.
         This works by allocating a socket to listen to port on the local
         side, optionally bound to the specified bind_address.  Whenever a
         connection is made to this port, the connection is forwarded over
         the secure channel, and the application protocol is then used to
         determine where to connect to from the remote machine.  Currently
         the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
         as a SOCKS server.  Only root can forward privileged ports.
         Dynamic port forwardings can also be specified in the configura‐
         tion file.

Hope this helps!

Terrance
  • 43,712
1

Unfortunately, this problem is intermittent and that has confounded my troubleshooting efforts. The answer @Terrance gave above, which I marked as The Answer, is actually not a solution to the problem for me. It seemed to work, and actually worked for a while. Then I ran into problems again. Sometimes stopping my ssh session and restarting it would cure the problem -- for a while -- and sometimes the restart would make no difference.

The suggestion mentioned this thread elsewhere -- i.e., to specify 127.0.0.1 rather than "localhost" in the browser's proxy settings -- likewise seemed to make a difference but was ultimately ineffectual. I previously answered that this was the critical difference between the browser connections working and not working, but again this was premature. I continued to experience intermittent problems in my browser's ability to make connections with websites through the tunnel.

I have now obtained enough additional experience with this problem and the solution I mention below that I am reasonably confident in my conclusion that there is a short-timeout bug of some kind in OpenSSH itself. BTW, my version is

OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips 1 Mar 2016

I base this on a) the fact that the problem is clearly browser-independent (verified in Firefox, Chromium and w3m) and b) the fact that using an alternate ssh client has reliably cured the problem.

I downloaded the source and built and installed PuTTY (from this link). NOTE: make sure you install virtual package gtkgl-dev so the PuTTY source can find the header files. Then I set it up just as I have in Windows so many times in the past, and it's been working a treat for about two days now. ZERO failures.

I am confident that this is the fix and that there is a bug in the current OpenSSH. I will work on making a report to that effect.

I am selecting my own answer as The Answer for purposes of this question, though @Terrence's answer above is still very useful reading.

JD Baldwin
  • 633