You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 5, 2021. It is now read-only.
This is similar to an issue I raised (and was later resolved) for non-VPC instances last year. It is a minor issue, as there is a workaround.
In the Instances tab, when you right-click on an instance inside a VPC but for which no Elastic IP has been assigned and select Connect to Instance, the connection attempt is made to the internal IP (e.g. 10.0.0.40) instead of the public IP (e.g. 184.73.123.112). This might be as intended.
However, after an Elastic IP has been assigned to the instance, remote connections are still attempted to the internal IP.
The workaround is simply to refresh the entire page, and then subsequent connection attempts are (correctly) made to the instance's public IP address.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is similar to an issue I raised (and was later resolved) for non-VPC instances last year. It is a minor issue, as there is a workaround.
In the Instances tab, when you right-click on an instance inside a VPC but for which no Elastic IP has been assigned and select Connect to Instance, the connection attempt is made to the internal IP (e.g. 10.0.0.40) instead of the public IP (e.g. 184.73.123.112). This might be as intended.
However, after an Elastic IP has been assigned to the instance, remote connections are still attempted to the internal IP.
The workaround is simply to refresh the entire page, and then subsequent connection attempts are (correctly) made to the instance's public IP address.
The text was updated successfully, but these errors were encountered: