Your browser does not allow storing cookies. We recommend enabling them.



Tunneling involves several addresses, as in, for example:

  sshg3 -L 2001:[::1]:2002

meaning "connect to the default SSH port on and start a tunnel on localhost:2001 which will forward to [::1]:2002", or:

  sshg3 -R 1234:remotehost:22 username@sshserver

meaning "connect to sshserver and start a tunnel listening on localhost:1234 forwarding to remotehost:22", where localhost refers to the machine on which the tunnel is being created. In this case, the AddressFamily in effect determines whether IPv4 or IPv6 is used.

Defining the listen part of a tunnel follows the same rules with respect to IP addressing as does listening on the server. The connection end of the tunnel is defined according to the same rules as any client connection.

There is nothing new to take into account for IPv6 and tunnels apart from the points mentioned for servers and clients. Tunnels can be established in as complex a way as desired and IPv4 and IPv6 can be mixed as wished.

The following examples illustrate some tunnel commands and their effects. In the examples, local1 and remote1 have both IPv4 and IPv6 connectivity; remote2 has IPv4 only:


Example 1: Local tunnel with IPv4 and IPv6

local1$ sshg3 -6 -L [::1]:4444:remote2:333 remote1#22422 1

local1$ netstat -tln
tcp        0      0 ::1:4444                :::*                    LISTEN

local1$ sshg3 localhost#4444 2

remote2$ netstat -a 3
SSHD2    00000010              Listen  
SSHD2    000005FA    Establsh

remote1$ netstat -a 4
SSHD22   00000382 Establsh
  Local Socket:                                 
  Foreign Socket:
SSHD25   0000030E Listen  
  Local Socket:   ::..22422                                           
  Foreign Socket: ::..0                                               
SSHD26   0000037D Establsh
  Local Socket:   fd02:2382:bb5a::36..22422                           
  Foreign Socket: fd02:2382:bb5a::54..44268

Connect to port 22422 on remote1, preferring to resolve the host name to an IPv6 address, and opening a tunnel listening on port 4444 on this host's local ::1 interface, and which connects to port 333 on host remote2.


Still on local1, connect to localhost, port 4444.


This will take us to remote2, where the netstat command shows a connection from remote1 to port 333.


On remote1, the netstat command shows the incoming connection from local1 to the server on port 22422 over IPv6, and the outgoing connection over IPv4 to port 333 on remote2.

Example 2: Remote tunnel with IPv4 and IPv6

local1$ sshg3 -R [fd02:2382:bb5a::36]:3333:remote2:333 remote1#22422 1

remote1$ netstat -c SERVER 2
SSHD21   00000375 Listen  
  Local Socket:   fd02:2382:bb5a::36..3333                            

remote1$ sshg3 -p3333 fd02:2382:bb5a::36 3

remote2$ netstat -a 4
SSHD2    000005F5   Establsh

Connect to remote1 via port 22422 and open a tunnel on the interface with address fd02:2382:bb5a::36 and port 3333.


The netstat command on remote1 shows this listening socket. The other end of the tunnel goes to port 333 on remote2.


A client on remote1 connects to [fd02:2382:bb5a::36]:3333 and ends up on remote2.


The netstat command on remote2 shows an established IPv4 connection between remote2 and local1.


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more