DNS – How to Set Up DNS Over SSH Tunnel

dnsmacosnetworkingsshtunnel

I want to setup my OSX system such that all network traffic is done through an SSH tunnel.

I've written a small script for this purpose, and these are the commands executed by it:

// setup tunnel
ssh -fN -D 1080 -p 22 user@remote

// start up redsocks
sudo redsocks -c /tmp/redsocks.conf -p /tmp/redsocks.pid

// forward all tcp traffic to tunnel
sudo ipfw add 0010 fwd 127.0.0.1,12345 tcp from me to any not dst-port 12345 not dst-port 1080 not dst-ip REMOTE_IP

I use redsocks to create an http proxy to my ssh-tunnel (so that i can forward all tcp traffic to it via ipfw), redsocks.conf looks like this:

base {
    log_debug = on;
    log_info = on;
    log = "file:/tmp/redsocks.log";
    redirector = generic;
}
redsocks {
    local_ip = 127.0.0.1;
    local_port = 55660;
    ip = 127.0.0.1;
    port = 1080;
    type = socks4;
}

Everything seems to work so far, all TCP traffic on my OSX system is done through the ssh tunnel, but the problem is with UDP traffic and because of that DNS queries are not working.

How can I get DNS on my local machine to work through the SSH tunnel?

Best Answer

Your ipfw … line only forwards TCP traffic. Maybe add the following line?

sudo ipfw add 0011 fwd 127.0.0.1,12345 \
                   udp from me \
                   to any not dst-port 12345 \
                          not dst-port 1080 \
                          not dst-ip REMOTE_IP

It's also a good idea to add set -x (for debugging) and set -e (to fail immediately if any of the commands fail).

One should generally use the term 'SSH tunneling' to refer to tun/tap with SSH.
Port-forwarding is a specific form of tunneling, but it should be still only be referred to as 'port forwarding' in this context.
Do not use SSH tunneling (as in -oTunnel and -oTunnelDevice) except for quick ad-hoc jobs.
- TCP over TCP is a very bad idea:
  - Why TCP Over TCP Is A Bad Idea
  - Understanding TCP over TCP: Effects of TCP Tunneling on End-to-End Throughput and Latency
- UDP over TCP inordinately adds latency to the applications that are normally making use of it. Programs that make use of UDP should have full control over their own reliability and congestion control, such as is the case for RTP.
DNS can use TCP as a transport. It is not restricted to UDP, though that is the preferred transport.

Related Solutions

Networking – Accessing Localhost Web Server via Reverse SSH Tunnel

-R 8080:localhost:80 is usually not enough. See man 1 ssh [emphasis mine]:

-R [bind_address:]port:host:hostport
[…]

Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side.

[…]

By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address *, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)).

Your tries with 127.0.0.1:8080 on the server indicate the listening socket is bound to the loopback interface. Most likely it is not bound to any other interface.

You need to explicitly specify bind_address or to use * or to use an empty string as bind_address. The option with an empty bind_address looks like this (note the leading :):

-R :8080:localhost:80

Additionally the state of GatewayPorts in the sshd_config on the server is important. From man 5 sshd_config:

GatewayPorts

Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be no to force remote port forwardings to be available to the local host only, yes to force remote port forwardings to bind to the wildcard address, or clientspecified to allow the client to select the address to which the forwarding is bound. The default is no.

To achieve what you want the option must not be no. Note no is the default value, so unspecified GatewayPorts still means no. The value of yes will make -R 8080:localhost:80 work like -R :8080:localhost:80.

I advise GatewayPorts clientspecified in the server config and ssh -R :8080:localhost:80 … on the client.

Possible additional problems:

The firewall on the server may block connections to the 8080 port coming in from the Internet.
The local HTTP server may reject requests that use example.com (compare Why does the original site work, but port forwarding to the same site fails?).

Best Answer

Related Solutions

Networking – Accessing Localhost Web Server via Reverse SSH Tunnel

Related Question