IBM Developer

Tutorial

IBM Power Virtual Server network security and address groups

A practical walk through for cloud security

By Arka Chakraborty, Bobichan P John, Sreevidhya Nair

On this page

IBM Power Virtual Server is an infrastructure as a service (IaaS) offering in IBM Cloud that allows you to deploy your current IBM i, IBM AIX, and Linux workloads in a hybrid cloud environment. It is a configurable, multi-tenant cloud environment with access to IBM Cloud services. In today’s cloud-driven world, securing network traffic is more critical than ever. As organizations deploy workloads in IBM Power Virtual Server, ensuring proper isolation between subnets and workloads is essential to prevent unauthorized access and security breaches. This is where network security groups (NSGs) and network address groups (NAGs) come into play. By combining NSGs and NAGs, you ensure that only the right traffic enters the right network segments, enhancing security and enforcing proper isolation between workspaces and subnets.

Why are NSGs and NAGs important?

When multiple types of workloads and applications run in a Power Virtual Server account, controlling communication between the workspaces, subnets, and external networks is necessary. With NSGs and NAGs, we can isolate and control cloud network traffic in IBM Power Virtual Server, ensuring secure segmentation and reducing the risk of data exposure. In summary, NSGs help enforce strict traffic rules to allow or block communication between different workloads and NAGs simplify rule management by grouping trusted IP addresses together, making access control easier and more scalable.

For a deep dive, check out the official IBM Cloud documentation on Network security groups.

Who is this tutorial for?

This tutorial is designed for cloud engineers, security professionals, and IT administrators working with IBM Power Virtual Server. If you manage cloud security, network segmentation, or workload isolation, this tutorial helps you understand how to use NSGs and NAGs to enhance security and achieve proper isolation in your cloud environment.

What you'll learn?

By following the steps in this tutorial, you can gain deeper understanding about:

  • Configuring NSGs to control both inbound and outbound traffic and enforce security rules
  • Using NAGs to group multiple IP addresses and streamline security management
  • Isolating workloads between subnets and workspaces
  • Implementing security policies using UI, CLI, and API

By the end of this tutorial, you will have a clear understanding of how NSGs and NAGs work, their real-world benefits, and how to apply them effectively to strengthen security and isolation in IBM Power Virtual Server.

Let us get started!

Prerequisites

Before you begin configuring NSGs and NAGs in IBM Power Virtual Server, ensure that the following requirements are met:

  • An IBM Cloud account and a Power Virtual Server granular cloud resource name (CRN) enabled workspace
  • The NSG feature on PER (Power Edge Router) enabled on both new and existing Power Virtual Server workspaces. This feature is not enabled by default on the new Power Virtual Server workspaces.
  • Knowledge of basic networking and network security, Power Virtual Server API/CLI/UI at user-level experience.

What is a Network Security Group (NSG)?

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 can 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 the systems that can communicate with each other within your workspace and ensuring a safer and more structured network environment.

Key features of NSG

  • Enhanced security: Helps prevent unauthorized access to virtual machines (VMs) and other network resources by enforcing network-level traffic control for inbound traffic.

  • Granular traffic filtering: Allows definition of security rules based on source IP, destination IP, port number, and communication protocols such as:

    • Transmission Control Protocol (TCP): Supports inspection of control flags like Synchronize (SYN), Acknowledgement (ACK), and so on.
    • User Datagram Protocol (UDP)
    • Internet Control Message Protocol (ICMP): Supports filtering by message types such as echo (ping request) and echo-reply (ping response).

  • Included at no additional cost: NSG functionality is bundled with IBM Power Virtual Server workspaces and does not incur extra charges.

  • No performance overhead: NSG enforcement operates efficiently without impacting network throughput or increasing latency.

  • Default behavior for traffic rule evaluation:

    • All inbound (ingress) traffic is denied by default, unless explicitly allowed by a user-defined rule.
    • All outbound (egress) traffic is allowed by default, and NSGs currently do not provide mechanisms to restrict outbound traffic.

Components of NSG

NSG includes the following components:

  • Members: Members are network interface cards (NICs) in an IBM Power Virtual Server workspace. A NIC can be added to an NSG using either its network interface ID or IPv4 address. A single NIC cannot be a member of multiple NSGs simultaneously.

  • Rules: Security rules define inbound traffic permissions by specifying criteria such as source IP address, destination IP address, port, and protocol.

What is NAG?

A network address group (NAG) is a collection of external network addresses Classless Inter-Domain Routing Addresses (CIRA) 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 NAG

  • Simplified rule management: Organizes external IP addresses efficiently.
  • Reduced complexity: Enhances the application of security policies across multiple addresses.
  • Improved scalability: Allows you to easily add new IP addresses or subnets to an NAG without modifying NSG rules.

Traffic rule evaluation order

NSGs in IBM Power Virtual Server support filtering of only incoming (inbound) traffic. When a packet is received, NSG rules are evaluated in a specific order to determine whether traffic should be allowed or denied.

Understanding this evaluation process is essential for implementing effective security controls:

  • Deny rules are evaluated first: If the incoming traffic matches any deny rule (based on parameters such as source IP address, destination IP address, port, and protocol), it is immediately blocked. No further rules are evaluated for that packet.
  • Allow rules are evaluated next: If the traffic does not match any deny rule, the system proceeds to evaluate the allow rules to determine if the traffic is permitted.
  • First matching allow rule applies: If multiple allow rules match the incoming traffic (that is, more than one rule permits the same traffic based on matching criteria), and there are no conflicts or overlapping deny rules, the first matching allow rule in the rule list is applied. This means rule order matters, and you should place more specific allow rules higher in the list to ensure that the correct one is enforced.

Estimated time

15 minutes

Preliminary steps

The following preliminary steps should be performed to verify and enable the NSG capability on an IBM Power Virtual Server workspace. NSGs provide the essential network-level security by allowing the definition and enforcement of traffic filtering rules for virtual machines and other resources. Because NSG support may not be enabled by default on all workspaces, these preliminary steps check the current NSG status, enable the feature if needed, confirm its activation, and verify that the default NSG and NAGs are created. This ensures that the workspace is properly configured to implement secure network policies and manage network traffic effectively.

  1. Get the workspace details and check if it has NSG capability set to true.

    % ibmcloud pi ws get ccf4b5db-c3a4-481d-a160-c6b2763f4d94 –json
{
“capabilities”: {
“cloud-connections”: false,
“custom-virtual-cores”: false,
“dedicated-hosts”: false,
“network-security-groups”: true,
“power-edge-router”: true,
~
},

  2. If NSG is not enabled, set the workspace target and perform NSG enable action.

    % ibmcloud pi ws tg crn:v1:staging:public:power-iaas:dal12:a/xxx:ccf4b5db-c3a4-481d-a160-c6b2763f4d94::
Targeting service crn:v1:staging:public:power-iaas:dal12:a/xxx:ccf4b5db-c3a4-481d-a160-c6b2763f4d94::…
% ibmcloud pi nsg act enable
Performing action enable on network security groups under account ACCOUNT1’s Account as user user@ibm.com…
OK
Action enable complete for network security groups.

  3. Verify that NSG is in the active state by listing the workspace capabilities again.

    % ibmcloud pi ws get ccf4b5db-c3a4-481d-a160-c6b2763f4d94 –json
“details”: {
“creationDate”: “2025-01-24T04:23:27.253Z”,
“crn”: “crn:v1:staging:public:power-iaas:dal12:a/xxxxxx:ccf4b5db-c3a4-481d-a160-c6b2763f4d94::”,
“networkSecurityGroups”: {
“state”: “active”
},

  4. Verify that the default NSG and NAG get created after successful NSG-enable action.

    % ibmcloud pi nsg ls
Listing network security groups under account ACCOUNT1’s Account as user user@ibm.com…
ID Name CRN
7e5ec44d-6e17-4da6-8e76-e1ae175b6cfc Default crn:v1:staging:public:power-iaas:dal12:a/xxx:ccf4b5db-c3a4-481d-a160-c6b2763f4d94:network-security-group:7e5ec44d-6e17-4da6-8e76-e1ae175b6cfc

After completing the pre-configuration tasks, we can try the following use cases.

Use case 1: Enforcing subnet isolation within a Power Virtual Server workspace using NSGs

Within a Power Virtual Server workspace, by default all subnets can communicate with each other without any traffic isolation. While this enables seamless connectivity, it can also create the following security risks when different subnets serve different purposes, such as development/test and production:

  • Unintended access between subnets can occur.
  • Accidental modifications may affect critical workloads.
  • Security vulnerabilities may arise due to unrestricted communication.

To mitigate these risks, NSGs are primarily used to enforce isolation between subnets by restricting inbound traffic. Unlike access control lists (ACLs), which manage granular traffic rules, NSGs focus on blocking unwanted access from subnets within the same workspace.

Network security groups:

  • Help isolate resources by preventing unwanted cross-subnet communication
  • Ensure sensitive workloads’ network traffic remains protected from unwanted access.
  • Maintain separation between different environments, such as production and development/test.

To understand how the NSGs enforce isolation between subnets in a Power Virtual Server workspace, let’s go through a step-by-step demonstration. This will show how NSGs can be used to restrict inbound traffic between subnets while allowing necessary access.

In this scenario, we have a Power Virtual Server workspace with two subnets and a VM deployed on each subnet.

  • Subnet A (production VMs) – Host critical applications and must be isolated from subnet B.
  • Subnet B (development and testing) – Used for development/test purposes and should not have access to Subnet A.

The following screenshots show Power Virtual Server UI listing of VMs, and subnets deployed in a NSG-capable workspace.



By default, as shown in the following screenshots, we can see that both the subnets can freely communicate as they exist within the same workspace. However, we will use NSGs to enforce isolation by blocking the inbound traffic from Subnet B to Subnet A.



In this scenario, we can use a NSG to isolate the two subnets from each other. To achieve this, we will first create one NSG in Subnet A.

For example, let us set up a new Power Virtual Server workspace in one of the production data centers and enabled NSG for that workspace. As part of the process, a default NSG was automatically created, and the network interfaces of the virtual machines (VMs) were added as its members.

In the default NSG shown in the following screenshot, the network interfaces of the virtual machines (VMs) were automatically added as members. Additionally, two inbound rules were generated by default.

  • The first rule allows traffic within the default NSG by setting the remote field to its own NSG ID. This implies that inter-subnet communication within the workspace is enabled by default.
  • The second rule allows traffic from the default NAG. In the default NAG, the automatically generated member is CIDR 0.0.0.0/0, which means external traffic from any source is allowed.

To achieve inter-subnet isolation, we need to modify the NSG rules and restrict traffic between subnets while allowing only the necessary connections. Next, let us remove the network interface of the Dev-system-AIX VM from the default NSG.

By doing so:

  • The Dev VM will no longer be part of the same security group as the Prod VM (Prod-system-AIX).
  • As a result, both the VMs will be completely isolated from each other, meaning they will not be able to communicate.

This step clearly demonstrates that we have successfully achieved complete network isolation between the two VMs, even though both the subnets belong to the same workspace.

The following screenshot shows details of the default NSG in the Power Virtual Server UI.

Connectivity between the Dev VM and Prod VM and the other way around has been completely restricted, ensuring full network isolation.



We can control the traffic flow between the Dev VM and Prod VM using the NSG rules. To demonstrate this, I’ve added a rule that allows Internet Control Message Protocol (ICMP) (ping) connectivity while blocking the Secure Shell (SSH) (TCP) access.

Refer to the following CLI-based approach to create NSG rules and associate them with the relevant VMs. A new custom NSG has been set up to demonstrate the scenario. However, the same outcome can also be achieved using the default NSG by adding the required rules.

  1. Create a custom NSG.

    % ibmcloud pi nsg create custom-nsg
Creating a new network security group custom-nsg under account ACCOUNT1’s Account as user@email.com… ID 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f
Name custom-nsg
CRN crn:v1:bluemix:public:power-iaas:mad04:a/xxx:612c3b13-54cb-469e-baa2-36e840a93656:network-security-group:9e8f99cf-f2fe-4e90-961d-5f9c862edd9f 
Default false

  2. As we know, once we enable NSG for one workspace, it creates a default NSG automatically and the network interfaces of the VMs will get added as its member automatically. As we have created one custom NSG and want to attach network interfaces of both those VMs here, remove the network interfaces of those VMs from the default NSG and add them to the custom NSG.

    % ibmcloud pi nsg ls
Listing network security groups under account ACCOUNT1 as user user@email.com… 
ID Name CRN
d163c327-6463-415f-a71c-ebbffe2bfad8 Default crn:v1:bluemix:public:power-iaas:mad04:a/xxx:612c3b13-54cb-469e-baa2-36e840a93656:network-security-group:d163c327-6463-415f-a71c-ebbffe2bfad8 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f  custom-nsg  crn:v1:bluemix:public:power-iaas:mad04:a/xxx:612c3b13-54cb-469e-baa2-36e840a93656:network-security-group:9e8f99cf-f2fe-4e90-961d-5f9c862edd9f

% ibmcloud pi nsg get Default
Getting network security group Default under ACCOUNT1 as user user@email.com… 
ID d163c327-6463-415f-a71c-ebbffe2bfad8
Name Default
CRN crn:v1:bluemix:public:power-iaas:mad04:a/xxx:network-security-group:d163c327-6463-415f-a71c-ebbffe2bfad8
Default true
Members
ID f1ab6cc6-dac7-426b-997e-8deb207fa5af Mac Address fa:16:3e:ae:35:b5
Target 80a6457b-4e6e-4113-9834-5a951110ae43
Type network-interface Rules
ID 36309fae-7ffc-44c7-930f-e614d37b4dfa
Action allow
Protocol Type all
Remote ID d163c327-6463-415f-a71c-ebbffe2bfad8
Type network-security-group
ID 67285ca8-991b-4de4-9cda-50362df5ac0b
Action allow
Protocol Type all
Remote ID Type default-network-address-group

  3. From the GET call of the default NSG, we can see that only one network interface (member ID: f1ab6cc6-dac7-426b-997e-8deb207fa5af) is attached to it. Therefore, now proceed to remove this member from the NSG.

    % ibmcloud pi nsg mr d163c327-6463-415f-a71c-ebbffe2bfad8 -m f1ab6cc6-dac7-426b-997e-8deb207fa5af
Removing member f1ab6cc6-dac7-426b-997e-8deb207fa5af from network security group d163c327-6463-415f-a71c-ebbffe2bfad8 under account ACCOUNT1 as user user@email.com… 
OK
Network security group member f1ab6cc6-dac7-426b-997e-8deb207fa5af was removed from network security group.

  4. Add this network interface along with the network interface of the other VM to the custom NSG.

    % ibmcloud pi nsg ma 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f -m network-interface -t 80a6457b-4e6e-4113-9834-5a951110ae43
Adding target 80a6457b-4e6e-4113-9834-5a951110ae43 with member type network-interface to network security group 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f under ACCOUNT1 as user@email.com…
ID d1cabfb1-3b31-483c-befe-a23732750686
Mac Address fa:16:3e:ae:35:b5
Target 80a6457b-4e6e-4113-9834-5a951110ae43
Type network-interface

% ibmcloud pi nsg ma 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f -m network-interface -t 50c2c449-f782-4e10-b775-4423b9245ccc
Adding target 50c2c449-f782-4e10-b775-4423b9245ccc with member type network-interface to network security group 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f under aACCOUNT1 as user@email.com…
ID 2e88422c-02cb-4c14-b933-e486e5fd079c
Mac Address fa:16:3e:fe:54:62
Target 50c2c449-f782-4e10-b775-4423b9245ccc
Type network-interface

  5. Issue a GET call on the custom NSG to verify if both network interfaces have been added successfully. Now, add two NSG rules to the custom NSG:

    • An ALLOW rule for ICMP traffic.
    • A DENY rule for TCP traffic to restrict SSH communication between the two VMs.
    % ibmcloud pi nsg ra 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f -a allow -p icmp -r network-security-group -g 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f Adding rule to network security group 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f under ACCOUNT1 as user@email.com…
ID f46df2f0-4df4-44e7-90a7-154f6ceaaf44
Action allow
Protocol ICPM
Type all Type icmp
Remote ID 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f 
Type network-security-group

% ibmcloud pi nsg ra 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f -a deny -p tcp -r network-security-group -g 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f Adding rule to network security group 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f under ACCOUNT1 as user@email.com…
ID 6c68e4ed-7498-49f8-9994-b4edaa770a16
Action deny
Source Port 1-65535
Destination Port 1-65535 Protocol
Type tcp Remote
ID 9e8f99cf-f2fe-4e90-961d-5f9c862edd9f
Type network-security-group

  6. In the UI, notice that the two rules have been successfully added to the custom NSG as expected. Additionally, we have set the same custom NSG as the remote NSG to enforce traffic restrictions within the workspace.



  7. Test the connectivity between the Prod and Dev VMs.



    As expected, the screenshots show that both virtual machines can successfully ping each other as the ICMP protocol is allowed. However, they cannot communicate through SSH because the TCP protocol is denied.

Use case 2: Security and address groups for subnets in two different Power Virtual Server workspaces

In the Power Virtual Server cloud environment, securing VM communication across different workspaces is crucial. Before implementing NSG and NAG, VMs in separate Power Virtual Server workspaces could communicate freely when connected to the same transit gateway.

This case demonstrates how NSG and NAG can regulate traffic between two Power Virtual Server workspaces, enforcing security policies to restrict or allow communication and ensuring isolation between workloads. As per the following figure the architecture consists of two Power Virtual Server workspaces:

  • Power Virtual Server Workspace-1, which contains:

    • VM-A in Subnet A
    • NSG applied to VM-A

  • Power Virtual Server Workspace-2, which contains:

    • VM-B in Subnet B
    • VM-C in Subnet C

  • NAG in Workspace -1 is configured with CIDR of Subnet C

  • Both the workspaces are PER-enabled and connected through a transit gateway, enabling unrestricted communication before applying security rules.

The following Power Virtual Server UI screenshots show the VMs deployed in Workspace-1 and Workspace-2.





Initially, all the VMs within these workspaces could communicate without restrictions through the transit gateway. This means:

  • VM-A can send and receive traffic to/from VM-B and VM-C.
  • VM-B and VM-C can also freely communicate with each other and VM-A.

As shown in the following screenshots, the VMs in both the workspaces can communicate with each other seamlessly. VM-A and VM-C should be able to ping each other.



To introduce controlled communication and isolation, you need to implement NSG and NAG as follows:

  • NSG on VM-A:
    • NSG is applied to regulate inbound traffic to VM-A.
    • A rule is set to allow/block traffic coming from Subnet C (where VM-C resides) based on security policy.
  • NAG-1 configuration:
    • A network address group (NAG-1) is created, containing the CIDR of Subnet C.
    • The NSG rule references NAG-1 to enforce traffic control policies dynamically.
    • Because NAG follows a most-specific match rule, if a source IP falls under a more specific CIDR within a custom NAG, that rule takes precedence.
    • As only the CIDR of Subnet C is defined in NAG-1, traffic from Subnet B will be blocked because the default NAG (0.0.0.0/0) is not used for matching when a specific NAG exists.
  • Isolation enforcement:
    • By applying NSG and NAG strategically, Subnet A can be isolated from Subnet C and Subnet B ensuring that VMs in different environments do not communicate unless explicitly allowed.
    • This helps with workload segmentation and security compliance.

First, we will create a custom NSG on VM-A along with a custom NAG. Although enabling NSG for a workspace automatically generates a default NSG and a default NAG—where the default NSG includes 0.0.0.0/0 as its member CIDR, allowing unrestricted traffic to the workspace—for demonstration purposes, we will create a custom NAG and explicitly define the CIDR of Subnet C to allow traffic exclusively from VM-C.

Custom NSG and custom NAG creation in Workspace-1:

% ibmcloud pi nsg create nsg-A
Creating a new network security group nsg-A under account ACCOUNT1 as user user@email.com…
ID 8fa08e69-f980-49ce-969c-3c06514c89a3
Name nsg-A
CRN crn:v1:bluemix:public:power-iaas:mad04:a/xxx:9fd7a0ee-aa1c-440a-8d83-226b072d3795:network-security-group:8fa08e69-f980-49ce-969c-3c06514c89a3
Default false

% ibmcloud pi nag create nag-1
Creating a new network address group nag-1 under ACCOUNT1 as user user@email.com… 
ID 07b6de18-2ad4-48c7-a14c-c087ea13bc30
Name nag-1
CRN crn:v1:bluemix:public:power-iaas:mad04:a/xxx:9fd7a0ee-aa1c-440a-8d83-226b072d3795:network-address-group:07b6de18-2ad4-48c7-a14c-c087ea13bc30

From the UI, get the details of the NAG as shown in the following screenshot:

Now, add the IP address of VM-A as a member of the NSG and the CIDR of Subnet C as a member of the NAG.

% ibmcloud pi nsg member-add 8fa08e69-f980-49ce-969c-3c06514c89a3 –member-type ‘ipv4-address’ –target 10.31.21.117
Adding target 10.31.21.117 with member type ipv4-address to network security group 8fa08e69-f980-49ce-969c-3c06514c89a3 under ACCOUNT1 as user user@email.com… 
ID ad5268d8-8abd-4d6b-b143-da758f8d5691
Mac Address Target 10.31.21.117
Type ipv4-address

% ibmcloud pi nag member-add 07b6de18-2ad4-48c7-a14c-c087ea13bc30 –cidr-block 192.168.38.0/24
Adding member 192.168.38.0/24 to network address group 07b6de18-2ad4-48c7-a14c-c087ea13bc30 under ACCOUNT1 as user user@email.com… ID 46a92b5c-2027-4342-a60c-a8410ccdba7c
CIDR Block 192.168.38.0/24

Let us configure a rule in the NSG to allow only ICMP traffic, specifying NAG-1 as the remote reference. This ensures that only ICMP communication is permitted between VM-C and VM-A, while all other traffic from Subnet C to Subnet A is blocked. Additionally, communication between Subnet B and Subnet A is also restricted due to the NAG CIDR matching rule.

% ibmcloud pi nsg rule-add 8fa08e69-f980-49ce-969c-3c06514c89a3 –action allow –protocol icmp –remote-type network-address-group –remote-group-id 07b6de18-2ad4-48c7-a14c-c087ea13bc30
Adding rule to network security group 8fa08e69-f980-49ce-969c-3c06514c89a3 under ACCOUNT1 as user user@email.com…
ID e83de86c-a183-4769-8414-e74e3a316267
Action allow
Protocol ICPM
Type all
Type icmp
Remote ID 07b6de18-2ad4-48c7-a14c-c087ea13bc30 Type network-address-group

Now, test the communication between VM-C and VM-A, as well as between VM-B and VM-A.

Testing the communication from VM-C to VM-A:

As expected, ping is working but SSH (TCP Protocol) is getting blocked due to NSG rule.

Testing the communication from VM-B to VM-A:

As expected, traffic from VM-B to VM-A is not reaching its destination due to the NAG’s CIDR matching rule. So, we can summarize from the use case:

In summary, from this use case, we can conclude that by implementing NSG and NAG in Power Virtual Server workspaces, organizations can:

  • Restrict unauthorized inbound VM communication.
  • Dynamically control access using CIDR-based NAG policies.
  • Ensure proper isolation between workloads and enforce segmentation.
  • Enforce IBM Power Virtual Server’s most-specific match rule for precise traffic control.
  • Enhance security and compliance within cloud environments.

Use case 3: Address groups for subnets cloud to Power Virtual Server access

Security in cloud environments is crucial, especially when managing inbound traffic from various IBM Cloud services. This case demonstrates how NSG and NAG can be used to restrict inbound traffic from the DNS server, Cloud Object Storage endpoints, time server, and virtual private cloud (VPC) network to an IBM Power Virtual Server workspace.

The purpose of this case is to ensure that only authorized network traffic reaches the IBM Power Virtual Server workspace while preventing unwanted access from IBM Cloud networking services. This is achieved through:

  • Defining NSG rules to block inbound traffic from specific IBM Cloud services.
  • Configuring NAG to specify allowed CIDR-based network access.
  • Enhancing security by limiting exposure to external IBM Cloud endpoints.

The architecture diagram in use case 3 consists of two key components:

  • IBM Cloud Services layer: This layer includes the following networking services that attempt to communicate with Power Virtual Server:

    • Cloud Object Storage network: Provides object storage access
    • DNS network: Used for domain name resolution
    • Time server: Ensures synchronized system time
    • VPC network: Supports private networking

  • Power Virtual Server workspace:

    • Virtual Machine (VM-A) in Subnet A
    • NSG enforcing inbound traffic restrictions
    • NAG specifying CIDR-based filtering rules

To demonstrate the use case, we have created a Power Virtual Server workspace and deployed an AIX virtual machine (VM-A) on Subnet A. Additionally, we have enabled NSGs on this workspace. As expected, enabling NSG automatically created a default NSG and a default NAG.



When the default NSG is created after NSG enablement, it creates two rules automatically.

Both inbound rules contain two Allow rules. One rule has its remote set to the default local addresses (default NSG), while the other has its remote set to the default external addresses (default NAG). This configuration implies that, by default, traffic from external IPs is permitted, as the default NAG includes a member with the 0.0.0.0/0 CIDR, allowing unrestricted external access.

To validate this, we attempted to ping the DNS server IPs (161.26.0.10 and 161.26.0.11), time server (time.adn.networklayer.com), and VPC IP (10.240.64.5) from the Power Virtual Server VM (VM-A). Due to the unrestricted external access, the ping should work without any issues.



Now, let us configure the NSG rules and use NAG for CIDR filtering to restrict inbound traffic from various IBM Cloud services, including DNS servers, ime Server, VPC, and others.

We have created two (NAGs that include the CIDRs of the DNS servers and the VPC. Additionally, we have defined two NSG rules: one that allows ICMP traffic from the VPC CIDR and another that explicitly blocks ICMP traffic from the DNS CIDR.

Custom NAGs can be created and VPC and DNS CIDRs can be added to those custom NSGs as shown in the following screenshots:





Remove the default NSG rules that were created during NSG enablement within the Default NSG and then add the required NSG rules.



The following screenshot shows two NSG ICMP rules. One rule allows inbound traffic from the VPC while the other rule denies inbound ICMP traffic from the DNS servers.

As shown in the following screenshot, note that the VPC IP (10.240.64.5) is reachable through a ping, whereas the DNS servers (161.26.0.10 and 161.26.0.11) are not reachable as expected.

This use case demonstrated how NSGs and NAGs can be effectively used to restrict inbound traffic from IBM Cloud services to Power Virtual Server. By implementing these security controls, organizations can protect their Power Virtual Server workloads while maintaining the necessary connectivity for essential operations. Additionally, NSG and NAG allow network isolation, ensuring that different workloads remain securely segregated from each other.

Summary

NSGs and NAGs are powerful tools that help organizations protect their cloud environments in IBM Power Virtual Server. These features provide a secure way to control network traffic, ensuring that only the right connections are allowed while blocking unauthorized access.

With NSGs, you can create custom security rules that determine the type of traffic that can enter or leave your network. These rules can be based on protocols, port ranges, and advanced filtering options such as TCP flags and ICMP message types. This level of control helps prevent security threats, limit unnecessary exposure, and maintain strict isolation between workloads running in different subnets and workspaces.

On the other hand, NAGs make security management easier by allowing administrators to group multiple trusted IP addresses together. Instead of manually defining each IP in an NSG rule, you can create an NAG and apply the rule to the entire group. This reduces complexity, saves time, and improves scalability as your network grows. Although we have covered three specific use cases, NSGs and NAGs offer even greater flexibility. Users can customize security policies based on specific network traffic patterns, combine the deny and allow rules, and automate configurations using CLI or API tools.

By carefully implementing NSGs and NAGs, organizations can:

  • Enhance security by blocking unauthorized traffic and isolating workloads.
  • Reduce risks of cyberattacks, unauthorized access, and internal threats.
  • Optimize network performance by ensuring that only necessary traffic is allowed.
  • Simplify management through automation and structured security policies.

In today’s cloud-driven world, securing your Power Virtual Server environment is more important than ever. With the right NSG and NAG setup, you can achieve better security, stronger compliance, and a well-protected cloud infrastructure without additional costs or performance impact.

References