Connecting to VMs

Generally you can connect to VMs on their “SRV” interface from the outside by calling:

$ ssh
Last login: Wed Feb 19 14:54:07 CET 2014 from on pts/0
Welcome to the Flying Circus!

However, due to a shortage of IPv4 addresses and an unpredictable status of IPv6 deployments, this might not work out of the box. Let’s go through a couple of options you have, if the example above does not work out of the box.

Getting an overview of your situation

VM has a public IPv4 address on SRV:

$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=57 time=29.110 ms
64 bytes from icmp_seq=1 ttl=57 time=25.364 ms
--- ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.364/27.237/29.110/1.873 ms

VM has a private IPv4 address on SRV:

$ ping
ping: cannot resolve Unknown host

VM is accessible through IPv6:

$ ping6
PING6(56=40+8+8 bytes) 2002:5e87:9a92:1:687c:1601:8692:c1e9 --> 2a02:238:f030:103::1d
16 bytes from 2a02:238:f030:103::1d, icmp_seq=0 hlim=59 time=27.642 ms
16 bytes from 2a02:238:f030:103::1d, icmp_seq=1 hlim=59 time=26.238 ms
16 bytes from 2a02:238:f030:103::1d, icmp_seq=2 hlim=59 time=25.941 ms
--- ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 25.941/26.607/27.642/0.742 ms

VM is not accessible through IPv6:

$ ping6
ping6: UDP connect: No route to host


If you get a result that isn’t shown here, please contact our support and we’ll amend this list.

VM has a public IPv4 address

Everything should be fine: independently of whether your ISP provides you with IPv4 and/or IPv6 you should be able to connect. If not: please contact our support.

VM has a private IPV4 address but you have native IPv6 from your ISP

Excellent! You should be able to connect as IPv6 will automatically pick up where IPv4 dropped the ball. If you can not connect in this scenario: please contact our support.

VM has a private IPv4 and you do not have native IPv6

This is the tricky part: the VM is only accessible via IPv6 directly from the outside but you don’t have it yet.

Using an IPv4 SSH jump host

SSH can perform complex connection setups including proxying through other machines. Fortunately there will always be at least one public IPv4 address that is accessible to you and you can use this to connect to the machine you actually want to go to.

Put the following in your ~/.ssh/config to enable transparent SSH jump hosts:

Host fcio-jumphost
  Hostname <VMNAME>

Host *
  ProxyJump fcio-jumphost

Host *
  ProxyJump fcio-jumphost

Remember to replace <VMNAME> with the name of a VM that has a public frontend IPv4 address configured. It doesn’t matter which other VM you connect to. Also, replace <USERNAME> with the unix username that you are using in the Flying Circus.

If you have an older SSH that doesn’t yet support the ProxyJump

Host *
    User <USERNAME>
    ProxyCommand ssh flyingcircus-jump-host -W %h:%p

Host *
    User <USERNAME>
    ProxyCommand ssh flyingcircus-jump-host -W %h:%p

Host flyingcircus-jump-host
    HostName <VMNAME>
    User <USERNAME>
    ProxyCommand none

Using a private OpenVPN server

If a project has an OpenVPN server available (external_net role), tunneling through a VPN connection may be a convenient alternative.

Using IPv6 rapid deployment options

Even if your provider does not provide you with IPv6 there is a good chance you can easily get IPv6 with one of the following “rapid deployment” options.

The technologies we recommend are:

  • 6to4 which works in many cases and is supported by Linux, Windows, Mac OS X and many routers. You can often turn this on for your whole office network by simply setting an “Enable 6to4” option in your router.

  • Teredo tunneling may be a last-resort option that can be configured on individual machines and is supported on Windows and Linux.

  • Traditional IP tunnels, like provided by Tunnelbroker are also an option, although their performance and reliability varies.

Further support

IPv6 deployment is gaining traction but the rapid deployment options are unreliable at times. Check above options or let us know if you found a solution that worked better for you. If you struggle, please contact our support: we’re here to help you through the hard times of IPv4 exhaustion!