Introduction

With the growing complexity of cloud infrastructures, ensuring strong security measures is more important than ever. To enhance network protection, IBM Power Virtual Server introduces Network Security Groups (NSGs)—a robust solution for controlling and securing network traffic. NSGs can be enabled only on PER and GCRN-enabled workspaces, allowing administrators to define security rules that govern inbound and outbound traffic to virtual machines (VMs). This helps restrict unauthorized access, enforce isolation between resources, and strengthen overall network security.

Alongside NSGs, Network Address Groups (NAGs) simplify security management by allowing administrators to group multiple external network addresses under a single entity. This reduces complexity when applying security rules and ensures efficient access control across cloud environments.

In this blog, I will explore the functionalities, benefits, and practical implementation of NSGs and NAGs in IBM Power Virtual Server environments. For demonstration purposes, I will use a UI-based approach, but the same results can also be achieved using CLI and API, providing flexibility based on user needs.

What is a Network Security Group (NSG)?

A Network Security Group (NSG) is a powerful security feature that helps control the flow of network traffic by allowing or denying specific connections. It plays a crucial role in securing resources deployed within an IBM Power Virtual Server workspace.

Earlier, in PER-enabled workspaces, when deploying virtual machines (VMs) across different subnets, there were no restrictions on how they communicated with each other. This meant that all VMs within the workspace could freely exchange data, regardless of which subnet they belonged to. While this setup was convenient, it also posed a security risk—any compromised VM could potentially affect others in the same workspace.

With the introduction of NSGs, this has changed significantly. Now, administrators have the ability to control inter-VM communication, even if the VMs are within the same subnet. This means you can create network isolation, ensuring that only necessary and authorized traffic flows between VMs.

Moreover, NSGs go beyond just internal security—they also help manage how traffic enters and exits the workspace. This means you can block unwanted external access, allowing only trusted sources to connect, which greatly enhances the overall security of your cloud environment. In short, NSGs act like a virtual firewall, giving you complete control over who can talk to whom within your workspace and ensuring a safer and more structured network environment.

Key Features of NSG

• Enhanced Security: Limits unauthorized access to virtual machines (VMs) and network resources.
• Traffic Filtering: Supports rules based on source, destination, port, and protocols (TCP, UDP, ICMP, and Any) ,flags SYN, ACK etc. for TCP and ICMP Message Type like echo, echo-reply etc
• Zero Additional Cost: Included as part of Power Virtual Server workspaces.
• No Performance Degradation: NSGs do not negatively impact network throughput or latency.

By default, all inbound (ingress) traffic is denied unless explicitly allowed through security rules, while outbound (egress) traffic is permitted.

What is a Network Address Group (NAG)?

A Network Address Group (NAG) is a collection of external network addresses (CIDRs) that are not directly related to provisioned network resources within a Power Virtual Server workspace. Instead of defining multiple external IP addresses or subnets individually in NSG rules, NAGs allow administrators to group multiple addresses under one entity, making security rule management more efficient.

Benefits of NAGs:

• Simplified Rule Management: Organizes external IP addresses efficiently.
• Reduced Complexity: Enhances the application of security policies across multiple addresses.
• Improved Scalability: Easily add new IP addresses or subnets to an NAG without modifying NSG rules.

NSG Components:

Members:

• Members are network interfaces (NICs) in a Power Virtual Server workspace.
• A NIC can be identified using either MAC address or IPv4 address.
• A member cannot belong to multiple NSGs simultaneously.

Rules:

• Security rules define inbound traffic permissions.
• Deny rules are evaluated first and take precedence over allow rules.
• If no allow rule matches, the default deny rule blocks the traffic.

Traffic Evaluation Order:

• Deny rules are processed first.
• If a deny rule is not matched, allow rules are checked.
• Overlapping allow rules do not conflict; the first matching rule is applied.

Setting Up NSGs and NAGs in IBM Power Virtual Server:

Enabling or Disabling NSGs:

To enable NSG in a workspace, verify that the workspace supports NSG by running:

ibmcloud pi ws get <WORKSPACE_ID> -o json

for example, I have picked one new workspace in Madrid02 DC to check if the workspace supports NSG :

We can see "network-security-groups": true in “capabilities” section of the Json output in the attached snapshot, so that means the workspace supports NSG capabilities , hence we can enable NSG in the IBM Cloud UI under the Workspaces section or by using CLI/API call.

To enable NSG using UI, we need to use NSG enable/disable button in workspace details pane after selecting the workspace.

If we want to enable the NSG using CLI we need to use the below command in IBM Cloud console and for API, we need to execute POST call for the endpoint /v1/network-security-groups/action with “action”: “enable” payload.

When the NSG (Network Security Group) feature is enabled on a workspace, a default NSG is created, including all existing NIC attachments. It has two default rules: one allowing all bidirectional communication among NSG members and another allowing communication with external networks (0.0.0.0/0). Deleting these rules ensures complete isolation, blocking all inbound traffic by default.

Creating an NSG in IBM Power Virtual Server:

1. Default NSG (No Rules or Members)

When NSG is enabled in a workspace, a default NSG is automatically created. Additionally, you can create a custom NSG without predefined rules or members. By default, all inbound traffic is denied unless specific rules are added later.

2. NSG with Inbound Rules and Members

For controlled access, you can define rules at the time of creation, Adding members to a network security group allows you to control inbound network traffic to these members. A member can only be associated with one network security group at a time.

• Allow/Deny: Specify whether to permit or block traffic.
• Protocol Selection: Choose TCP, UDP, ICMP, or Any based on your needs.
• Source & Destination Ports: Define which port ranges are open for communication.
• Remote Sources: Use NSGs or NAGs to control traffic from specific external networks.

💡 Tip: It’s recommended to use least privilege access—only allowing necessary traffic while denying everything else.

The snapshot below shows that a default NSG is automatically created when NSG is enabled on the workspace. It includes two predefined rules: one allowing bidirectional communication among NSG members and another permitting communication with external networks (0.0.0.0/0). Additionally, I have created a custom NSG without any predefined rules or members.

Understanding NSG Rules and Fine-Grained Traffic Control:

In IBM Power Virtual Server, Network Security Groups (NSGs) regulate inbound traffic through defined security rules. If source or destination ports are not specified, NSG automatically applies the full port range (1–65535) by default.

For TCP traffic, NSGs provide additional filtering capabilities using flags:

• ACK – Acknowledges a received packet.
• FIN – Indicates the end of a communication session.
• RST – Resets an existing connection.
• SYN – Initiates a new connection.

Similarly, ICMP traffic can be controlled at a granular level by specifying ICMP message types, allowing precise security configurations:

• all – Includes all ICMP messages.
• echo – Used for ping requests.
• echo-reply – Response to a ping request.
• source-quench – Informs the sender to slow down data transmission.
• time-exceeded – Indicates packet lifetime expiration.
• destination-unreach – Signals that the destination is unreachable.

These advanced filtering options help refine security policies, ensuring better traffic control and network protection within IBM Power Virtual Server environments.

Here I have attached one snap of NSG rule addition pane for your understanding

Understanding Network Address Groups (NAGs) in IBM Power Virtual Server:

A Network Address Group (NAG) is a collection of external IP address ranges (CIDRs) that simplifies inbound traffic management in IBM Power Virtual Server. It helps group multiple external IPs or subnets under a single entity, making it easier to apply security rules.

Default NAG vs. Custom NAGs

1. Default NAG

• Created automatically when NSG is enabled in a workspace.
• Contains CIDR 0.0.0.0/0, meaning it includes all IP addresses.
• Allows unrestricted external traffic unless modified.

2. Custom NAGs

• Users can create up to 10 NAGs per workspace.(Though it is soft limit of NAG and NSG per workspace, the quota can be increased as well using support request )
• Helps control traffic from specific external networks (e.g., IBM Cloud private endpoints).
• Uses CIDR notation (192.168.1.0/24, 10.0.0.0/16) to define external IP ranges.
• A CIDR cannot be part of multiple NAGs
• By leveraging NAGs effectively, users can better manage inbound traffic, enforce security policies, and optimize their cloud network architecture.

Here in this below snap, it is showing NAG creation pane in UI, where I am adding VPC CIDR as NAG’s member CIDR

Precedence Rule in NAG Traffic Matching:

When allowing or denying traffic from a Network Address Group (NAG), IBM Power Virtual Server follows a most-specific match rule.

How It Works:

• The source IP is checked against custom NAGs first.
• If the IP belongs to a more specific CIDR within a custom NAG, that rule applies.
• The default NAG (0.0.0.0/0) is not used for matching if a specific NAG exists.

Example Scenario:

• A remote system has the IP 10.55.55.2.
• A custom NAG exists with CIDR 10.55.55.0/24.
• To allow traffic from 10.55.55.2, the NSG rule must explicitly allow traffic from that custom NAG.
• Default NAG (0.0.0.0/0) will not be used for this IP.

This approach ensures better security and precise traffic filtering, preventing broad access from the default NAG when a more specific match is available.

Example Scenario for NSG and NAG:

I deployed two AIX VMs in the workspace. If no NSG is specified during deployment, the VM's NIC is automatically added to the default NSG and must be manually reassigned to a custom NSG if needed. The workspace is connected to a transit gateway, linking it to a VPC VM acting as a remote site. By default, the VPC VM can ping the PowerVS AIX VMs, and this traffic flow can be controlled via NSG.

I can see NICs of those both VMs are now part of member list of default NSG :

Before Applying NSG custom rules, I can able to ping or ssh to those powers VMs from VPC VM:

I have configured a custom rule within the default NSG to permit ICMP traffic while explicitly denying TCP communication. As the remote entity, I designated a custom NAG that includes the VPC CIDR as its member. Additionally, I removed both default rules from the NSG to enforce stricter traffic control.

Now as expected SSH is not working to those AIX VMs from VPC VM but ping is working fine.

Initially, I permitted only ICMP traffic, allowing ping functionality while restricting SSH access. Subsequently, I removed the ICMP rule and enabled TCP communication with port 24 as the destination port range, inadvertently blocking both ping and SSH, as SSH operates on destination port 22. Upon explicitly allowing port 22, SSH connectivity was successfully restored.

Now allowing TCP protocol with destination port 22 , so as expected SSH connection restored.

Within the workspace, AIX VMs should inherently be able to communicate with each other; however, this interaction can be regulated using NSG rules. To demonstrate this, I configured an NSG rule that denies ICMP traffic while permitting TCP communication and designated the Default NSG itself as the remote entity. As a result, ping functionality between the VMs was disabled, while SSH connectivity remained operational as expected.

Before imposing NSG rules, connectivity between AIX VMs are working fine.

After imposing NSG rule with ICMP deny and TCP allow, ping is not working and SSH connectivity is working fine between those VMs

Conclusion:

Network Security Groups (NSGs) and Network Address Groups (NAGs) play a critical role in securing IBM Power Virtual Server environments by controlling inbound traffic with precision. By leveraging custom security rules, protocols, port ranges, and advanced filtering options like TCP flags and ICMP message types, organizations can achieve fine-grained traffic control tailored to their security needs.

While this blog covers a few example combinations, NSGs offer extensive flexibility, allowing users to define various rule sets based on specific traffic patterns. By strategically implementing deny and allow rules, integrating custom NAGs, and utilizing CLI or API for automation, you can enhance security, reduce risks, and optimize network performance.

For further details on CLI and API-based NSG management, refer to the NSG Documentation  https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-nsg