Networking Problems

This section lists problems that you might encounter while setting up security rules to implement firewalls for your instances.

Can’t connect to an instance using SSH

Description

I've created an instance but can’t connect to it using SSH.

Solution

Check for each of the following possible causes:

Is your instance configured for SSH access?

All Oracle-provided Oracle Linux and Solaris instances are by default configured to allow SSH access. However, if you’re creating an instance using a private image or an image from Oracle Cloud Marketplace, the instance might not be configured to allow SSH access. Check with the owner of the machine image.

Remember, also, that you can’t access Windows instances using SSH. If you’re trying to log in to a Windows instance, use RDP. See Accessing a Windows Instance Using RDP.
Did you use the correct user?
- To log in to an instance that was created by using an Oracle-provided Oracle Linux machine image, use the opc user.
  
  For instances created by using other machine images, find out which SSH-enabled users are defined in that machine image, and log in as one of those users.
- To log in to an instance as a user that was created after the instance was provisioned, you must generate an SSH key pair for the new user and copy the public key to the ~/.ssh/authorized_keys file of the user. You must also add the new user to the list of allowed users in the /etc/ssh/sshd_config file on the instance. See Adding Users on an Oracle Linux Instance.
Did you specify the correct public IP address of the instance?

To find out the public IP address of your instance, view the information on the Instances page. See Listing Instances.

If no public IP address is associated with the instance, reserve and associate a public IP address. See Reserving a Public IP Address and Updating an IP Reservation.
Did you specify the correct private key?

The private key that you specify must correspond to one of the public keys associated with the instance.
Does the instance belong to a security list with the inbound policy set to deny?

An instance can be associated with multiple security lists. You can find out which security lists an instance is attached to by viewing the details of the instance. See Monitoring Instances.

You can see the policies used by each security list by viewing the details of the security list from the web console.

If there’s a conflict between the policies of the various security lists, then the most restrictive policy is applicable. This means that if even one of the security lists that your instance is attached to has the inbound policy set to deny, then your instance can’t receive traffic.

If this is the case, then create a security rule to explicitly allow traffic to a security list that your instance is attached to.
Does the error message contain the following warning?

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

If yes, then see RSA key fingerprint error while connecting to an instance.

RSA key fingerprint error while connecting to an instance

Description

When I try to SSH to my Compute Classic instance, I get a warning message like the following:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d2:aa:50:d4:ff:dc:76:1d:16:95:4a:77:c4:12:87:0f.
Please contact your system administrator.
Add correct host key in /home/joe/.ssh/known_hosts to get rid of this message.
Offending key in /home/joe/.ssh/known_hosts:63
RSA host key for 11.12.13.14 has changed and you have requested strict checking.
Host key verification failed.

Solution

This error occurs when you use SSH to connect to an Oracle-provided Oracle Linux instance that has a new RSA key fingerprint.

The RSA key fingerprint of a Compute Classic instance changes when, for example, an instance that isn’t set up to boot from a persistent disk is re-created. When you first connected to your Compute Classic instance, the original RSA key fingerprint was stored on your local host. Subsequently, whenever you use SSH to connect to your instance, the instance sends its current fingerprint. The SSH client compares the received fingerprint with the locally stored fingerprint. If the fingerprints don’t match, then this error occurs, and the ssh command fails.

Note that this warning message is returned by the OpenSSH client on an Oracle Linux host. If you’re using a different SSH client or a different operating system, then the error message may be different.

To solve this error, you must remove the old (and now invalid) RSA fingerprint of the instance from the local host.

In Linux, the RSA key fingerprints are usually stored in the /home/user/.ssh/known_hosts file on the host from which you are trying to ssh to the instance. Each line in this file starts with the IP address or host name of a remote host. Open the file in a text editor, identify the line corresponding to the IP address of the instance that you’re trying to access, and delete that line.
In Windows, by default, PuTTY stores keys for known hosts in the HKEY_CURRENT_USER\SoftWare\SimonTatham\PuTTY\SshHostKeys registry. Each key has a name in the format, rsa2@22:ip_address. Using the Registry Editor, identify the key corresponding to the IP address of the instance that you’re trying to access, and delete it.

Caution:

Improper use of the Windows Registry Editor can cause serious problems. Before you do this, make sure that you’re aware of the associated risks. See the documentation accompanying the operating system of your local host.

The next time you use SSH to connect to the Compute Classic instance, a message is displayed indicating that the authenticity of the host can’t be established. At the prompt to continue connecting, enter yes. The new fingerprint is added to the local host, and the connection goes through.

Can’t get instances to communicate with each other

Description

I’ve created multiple instances, but am unable to configure them to communicate with each other.

Solution

By default, instances can communicate with each other only if they’re part of the same security list. If your instances aren’t part of the same security list, then you can add them to a security list, as described in Adding an Instance to a Security List. Alternatively, if you want to keep your instances in separate security lists, then you can define security rules that enable all instances in a specified security list to communicate with all instances in another security list. See Managing Security Rules.

My instance can’t connect to instances in another IP network using an IP network exchange

Description

I created an instance using an Oracle Linux 5.11 image and added multiple interfaces of the instance to different IP networks. Some of the IP networks are connected to other IP networks through an IP network exchange. However, my instance can’t send or receive traffic from instances on any of the IP networks that are connected over an IP network exchange.

Solution

On instances created using Oracle Linux 5.x images or any image that doesn’t support DHCP option 121, when you add the instance to multiple networks, the routes to the IP network exchanges aren’t added automatically in the instance route table. This prevents the instance from sending or receiving traffic to and from instances on other IP networks using IP network exchanges. However, the instance can send and receive traffic from other instances on IP networks that it is added to directly (not through an IP network exchange).

You can manually add the required routes in the routing table. Add one route for each IP network connected through an IP network exchange.

For example, consider an instance with two network interfaces. One network interface, eth0, is configured as the default gateway on either the shared network or on an IP network. Another network interface, eth1, is added to IPNetwork1 which has the CIDR 10.32.1.0/24. This IPNetwork1 belongs to an IP network exchange, say IPX1. If another IP network, say IPNetwork2 with CIDR 10.32.2.0/24, also belongs to the same IP network exchange, IPX1, then to add a route to IPNetwork2, run the following command on the instance:

ip route add 10.32.2.0/24 via 10.32.1.1

In this example, 10.32.2.0/24 describes IPNetwork2 in CIDR format, that is, the IP network that you want to exchange traffic with.

10.32.1.1 is the default gateway of IPNetwork1, that is, the IP network that the instance is added to. Here both IP networks must belong to the same IP network exchange.

On a Windows instance, for the same scenario, run the following command:

route add 10.32.2.0/24 10.32.1.1

Can’t access my instance even though it has a public IP address

Description

I created an instance and associated a public IP address with it. I had earlier created an instance that doesn’t have a public IP address. I tried to access the second instance from the first instance, but ssh times out without connecting.

Solution

An instance that doesn’t have a public IP address can connect to any other instance only over the private IP address of the destination instance. If you attempt to connect to the public IP address of the newer instance, it will fail.

For example, let's say you created Inst1 without a public IP address. You subsequently created Inst2 and associated a public IP address with Inst2. Now Inst1 can connect to Inst2 using the private IP address of Inst2. However, Inst1 can’t connect to Inst2 using the public IP address of Inst2.

To find out the public IP address of your instance, view the information on the Instances page. See Listing Instances.

Can’t remove an IP address from an instance

Description

I associated a temporary IP address with my instance while creating the instance using the Create Instance wizard. Now I want to remove the temporary IP address and use an IP address reservation instead. How can I remove the temporary IP address from my instance? The Remove Instance option in the web console is disabled.

Solution

You can’t remove a temporary IP address from an instance. You can only remove a persistent IP address. If you created an instance with an autogenerated IP address or if you changed the status of the IP address associated with an instance to temporary, then to remove that IP address from the instance, first update it to change its status to permanent. See Updating an IP Reservation.

Can’t delete a security application

Description

When I tried to delete the security application /oracle/public/snmp-trap-udp, the following error message was displayed:

APIUnauthorizedError: User /Compute-acmecorp/acmeadmin is not permitted to perform "secapplication.delete" on secapplication: /oracle/public/snmp-trap-udp

Solution

Compute Classic has a set of predefined security applications. The names of these security applications start with /oracle/public container. You can’t delete these predefined security applications.

Tip:

To view a list of predefined security applications from the web console, click the Network tab and then the Security Applications tab in the left pane. The list of available security applications is displayed. In the search field, enter /oracle/public, and click . A list of all the predefined security applications is displayed.

To get a list of all the predefined security applications from the CLI, use the opc compute sec-application list command and specify /oracle/public as the container. For help with that command, run the command with the -h option. For the instructions to install the CLI client, see Preparing to Use the Compute Classic CLI in CLI Reference for Oracle Cloud Infrastructure Compute Classic.