Contents


Since 2023 when AWS announced it would begin charging for a public IPv4 address I have been investigating eliminating the need for a public IPv4 address. It was relatively easy to move from an IPv4 only aws ec2 instance to a dual stack instance that can communicate via both IPv4 and IPv6. I also quickly determined that I would not be able to completely eliminate the need for a public IPv4 address for the foreseeable future. With the IPv6 only workarounds I am able to reduce the need for a public IPv4 address as long as I have access to an instance or server with dual stack IPv4 and IPv6 access.

I had already been using the aws instance for proxy access to the internet and immediately found that the ssh proxy I was already using gave me access to both IPv4 and IPv6 servers from a machine that did not have a public IPv6 address.

In 2024 while working on IPv6 only workarounds I found that the ssh tunneling solutions I had been using as early as 2018 to allow me to get around resort or hotel internet access restrictions could be utilized to allow an aws instance without a public IPv4 address to access both github and ak20 which only support IPv4 access.

This IPv6 only workaround makes use of ssh to aws connectivity

This IPv6 only workaround makes use of ssh to aws connectivity and requires the aws.lam1.us instance to be up. I have run an aws.lam1.us instance 24/7 since 2017 and it has been a dual stack instance capable of both IPv4 and IPv6 communications since 2023.

This is my fifth IPv6 only workaround the first four of which were designed to be used by the cloud init process. This workaround is designed to facilitate interactive activity after the instance is up. So far all the IPv6 only workarounds use the ssh to aws connectivity except in the cases where the instance is in the us-west-2 Oregon region and can access the git repository store, tar archives, db archives and such from the aws-efs directly.

It was created primarily so that I can work with git repos using fetch, push and pull commands from both the github and ak20 git repository stores with minimal latency. The ak20-aws-gateway and ak20 entries also enable me to implement backups to ak20 or refresh operations from ak20 from an instance without a public IPv4 address using the ssh to aws connectivity.

The ssh to aws connectivity is implemented with private keys in the user bash resources installed from the aws-efs for the region as well as known_host entries and more from the LAM aws-efs metadata directory all installed during initialization by cloud init when a new instance is launched.

This IPv6 only workaround works for git when git uses standard ssh protocols. This solution does not work for git over the https protocol. The Connecting to GitHub with SSH documentation should help with with setting up access to GitHub with ssh.

Enable github and ak20 remotes using aws-gateway access on instance without public IPv4 access

.ssh/config entries for aws-gateway access to ak20 and github

Using two local ssh aws-gateway processes implementing a LocalForward via aws.lam1.us and the .ssh/config entries for those processes and the host entries specifying the port for the process I was able to get a repo connected to both github and ak20, the main repo stores, from an instance without a public IPv4 address. Like other IPv6 only workarounds this requires ssh connectivity to the aws.lam1.us instance that has a dual stack and supports both IPv4 and IPv6 connections.

All these entries are added to .ssh/config for the user on the machine needing the aws-gateway access. 

Host ak20-aws-gateway
LocalForward 59222 ak20.lam1.us:55520
Port 55520
Hostname aws.lam1.us

Host ak20 ak20.lam1.us
Port 59222
Hostname localhost

Host github-aws-gateway
LocalForward 58222 github.com:22
Port 55520
Hostname aws.lam1.us

Host github.com
Port 58222
Hostname localhost

This entry overrides the DNS entries for access to github.com to use the localhost port and the aws-gateway process forwarding through aws.lam1.com that has dual stack IPv4 and IPv6 connectivity allowing an instance without a public IPv4 address to access a host only acessible via IPv4.

Start aws-gateway processes

ssh -f -C2qTnN ak20-aws-gateway
ssh -f -C2qTnN github-aws-gateway

Each of the above commands starts a process on the localhost that tunnels through the aws gateway via a localhost port that the .ssh/config entry uses when the gateway hostname is specified.

Test access

ssh ak20
ssh -T git@github.com

The .ssh/config file entries direct ssh to use the tunnel process previously started using the aws-gateway .ssh/config entries.

Without the .ssh/config file entries an instance without a public IPv4 address gets a "Connection timed out" error after what could be a couple of minutes or more depending on configuration.

Update git remote entries to use .ssh/config host names

REPO=aws # no-ssl
REPO=lam # Private reps not on github
cd /var/www/${REPO}
git remote set-url origin git@ak20:${REPO}
git remote add github git@github.com:LAMurakami/${REPO} # For public repos only

The github.com entry is the same as would work on an instance with a public IPv4 address without the .ssh/config entries and ssh processes.

Enable SOCKS5 ssh proxy

I have been using a SOCKS5 ssh proxy for more than a decade since 2012 or earlier. The SOCKS5 ssh proxy gives me some of the advantages of a VPN using a tunnel process on the localhost connected to a ssh server instead of a VPN client.

In 2023 I discovered that this process gives a host with only IPv4 or IPv6 access dual stack IP access with no change other than the proxy server used having dual stack IP access.

See Also: http://arsc.lam1.us/SSH_SOCKS5_Proxy

alias entries for starting and reporting on a SOCKS5 ssh proxy

alias sp='ssh -f -C2qTnN -D 1080'

This starts a process on the localhost that tunnels through the specified gateway via a localhost port that the .ssh/config entry uses when the gateway hostname is specified. 

alias rp="ps -ef | grep 'ssh -f' | grep -v grep"

Start SOCKS5 ssh proxy

sp aws # or ak20 or any sever with ssh access that allows tunneling

I have been typing "sp aws" since as early as 2017 and "sp alpha" since as early as 2012 to start the process on the localhost that supports the use of a SOCKS5 ssh proxy. I have also used "sp ak20" or earlier LAM Alaska LAN servers for proxy access that allows me to see all the machines on the LAM Alaska LAN using Firefox and it's proxy configuration capabilities.

Report SOCKS5 ssh proxy and ssh tunnel processes

rp # ps -ef | grep 'ssh -f' | grep -v grep

Requirements

This workaround requires ssh connectivity to a dual stack host with both IPv4 and IPv6 public addresses. That ssh connectivity must include the ability to do SSH Tunneling (Port Forwarding). Local port forwarding is often used to connect to a remote service on an internal network and could be blocked or restricted by the server administrators. A non privileged user can use ports greater than 1024 as a LOCAL_PORT. In this case we will use the ssh local port forwarding to bridge to an IPv4 only server from an IPv6 only instance using an intermediate dual stack server.

The AllowTcpForwarding option in the OpenSSH server configuration file must be enabled on the server to allow port forwarding.

Pros and Cons

Pros

  • Only one port is required for a SOCKS 5 ssh proxy that can be used by Firefox as a proxy for all communication with the internet.
  • A target server that was otherwise unaccessble can now be accessed with this workaround as long as access is via standard ssh protocols.
  • There are a lot of ports available.

Cons

  • A dedicated port, process and configuration settings are required for each target server to be directly addressed with this workaround.

About this page

This page was created to document using aws-gateway tunnels and .ssh.config host entries as an IPv6 only workaround.

This page was created as a How To for myself and includes cut and paste sections that can be used to implement and use what is documented. It does reference the SSH SOCKS5 Proxy page created more than a decade ago that documents options used in the SSH command, Firefox proxy configuration and more but assumes the reader has a pretty good knowledge of Linux, SSH, IP communications, and more or will be able to gain that knowledge from other sources.

I do believe this page has information that could help others so publishing the page might help but they would have to be able to find the page and have sufficient knowledge and understanding to use it in their situation.

My case is very specific. I am using this workaround along with others to limit the number of public IPv4 addresses I have to pay AWS for at about $43.80 per Year to one except for testing. My calculations and estimates have AWS making hundreds of millions per year charging for the public IPv4 addresses they already have.

Log

  • On Wednesday, June 5, 2024 I setup ak20-aws-gateway on lam3 like ak17-aws-gateway on ak19.
    • I used the Port Forwarding#Setup and use a ssh tunnel to ak17 via aws or lam2 as a gateway documentation from 2018.
    • I did not need ak17-lam2-gateway which used the 443 alternate port for ssh on a lam2 instance which allowed me to get out of a Resort or Hotel LAN that was blocking ssh on the standard port of 22. I haven't had to utilize this for years since the resorts I visit have stopped trying to block port 22 ssh connections.
    • Added documentation on SOCKS5 ssh proxy process I have been using since 2012 or earlier.
      • I was officially allowed to use the SOCKS5 ssh proxy process to access DoD HPCMP resources when working at home for ARSC after documenting it and requesting it's authorization. At the time the DoD HPCMP provided proxy or VPN services but access was tailored to Windows users and Linux workstation users were not well supported.