Skip to main content

Security Groups — Troubleshooting

This document covers common issues when working with Security Groups and how to resolve them.

Issue 1: Rule added but traffic is still blocked​

Symptom: You created an Allow rule for a specific port or protocol, but connections to (or from) the resource still fail.

Common cause: The Security Group has not been attached to the target resource, or the resource is using a different Security Group.

Resolution:

  1. Go to the resource's configuration page (for example, the virtual server detail page).
  2. Check the Security Groups section under network settings — confirm that the Security Group you configured the rule for appears in the attached list.
  3. If it is not attached, add the Security Group to the resource through the resource configuration page.
  4. If the resource is using multiple Security Groups, check whether a Deny rule in another Security Group is overriding the allow.

Issue 2: Cannot delete a Security Group​

Symptom: When clicking Delete, the system displays an error message and the deletion cannot be performed.

Cause: The Security Group is currently attached to one or more resources. The system does not allow deleting a Security Group that is in use, to avoid disrupting network connectivity.

Resolution:

  1. On the list page, check the Apply to column for the Security Group — this column shows the number of resources currently using it.
  2. Go to each listed resource, navigate to its network settings, and detach this Security Group.
  3. Once the Apply to column shows 0 (no resources attached), retry the delete operation.

Note: When detaching a Security Group from a resource, ensure the resource still has at least one other appropriate Security Group attached to avoid losing network connectivity.

Issue 3: Rule appears in the list but traffic is still blocked​

Symptom: The Allow rule was created successfully (status Active) and the Security Group is attached to the resource, but the connection still fails.

Common cause: Wrong direction (Inbound/Outbound), wrong protocol, or wrong port.

Resolution:

  1. Check traffic direction: Connections to the resource require a rule in the Inbound rule tab; connections from the resource require a rule in the Outbound rule tab. Ensure the rule is in the correct tab.
  2. Check Protocol: Confirm that the protocol (TCP, UDP, ICMP) in the rule matches the actual traffic type. For example, DNS typically uses UDP on port 53, not TCP.
  3. Check Port range: Ensure the port in the rule covers the port the service is listening on. For example, if the application runs on port 8080, the rule must open port 8080, not 80.
  4. Check IP type: If the connection uses an IPv6 address, a rule with IP type set to IPv6 must exist; an IPv4 rule does not apply to IPv6 traffic.
  5. Check Sources / CIDR: The source IP address of the connection must fall within the CIDR range declared in the rule. If unsure, temporarily set 0.0.0.0/0 to confirm the issue is not with the CIDR.

Issue 4: Security Group or rule status stuck at "Pending"​

Symptom: After creating, updating, or deleting a Security Group or rule, the status shows Pending for an extended period (more than a few minutes) without transitioning to Active.

Cause: The operation is still being processed by the infrastructure, or there is a temporary issue with the network service.

Resolution:

  1. Refresh the page (F5) after 1–2 minutes to check whether the status has updated.
  2. If the status remains Pending after 5 minutes, try performing the operation again (for example, re-save the rule, or delete and recreate the Security Group).
  3. Check whether any system incident notices are posted on the FPT Cloud announcements page.
  4. If the issue persists after 15 minutes, contact FPT Cloud technical support with the following information: Security Group name, VPC ID, and the time the issue first appeared.