Virtual Network Services

Firewall

By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is also blocked by default.

Ingress Firewall Rules

Incoming traffic filters are configured in different locations depending on the network type in use.

• For isolated networks, incoming filter rules are applied on the public IP address associated with the network. Each public IP can have its own set of rules that control and filter traffic originating from the internet.

• For VPC networks, incoming traffic is filtered through VPC Access Control Lists (ACLs). Traffic handling is determined by the ACL rules attached to each network tier within the VPC.

• For shared networks, incoming filter rules are managed through security groups. Each resource deployed in a shared network is associated with one or more security groups, and filter rules are defined within those groups.

Below is the procedure of creating a firewall rule on a public IP address associated to an isolated network

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. Click the name of the network where you want to work with.
4. Click Public IP Addresses tab.
5. Click the IP address you want to work with.
6. Click the Firewall tab and fill in the following values.
   
   • Source CIDR: (Optional) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave empty to allow all CIDRs.
   • Protocol: The communication protocol in use on the opened port(s).
   • Start Port and End Port: The port(s) you want to open on the firewall. If you are opening a single port, use the same number in both fields
   • ICMP Type and ICMP Code: Used only if Protocol is set to ICMP. Provide the type and code required by the ICMP protocol to fill out the ICMP header. Refer to ICMP documentation for more details if you are not sure what to enter
7. Click Add.

Egress Firewall Rules

The egress traffic originates from a private network to a public network, such as the Internet. By default, the egress traffic is blocked in default network offerings, so no outgoing traffic is allowed from a guest network to the Internet. However, you can control the egress traffic by creating egress firewall rules. When an egress firewall rule is applied, the traffic specific to the rule is allowed and the remaining traffic is blocked. When all the firewall rules are removed the default policy, Block, is applied.

Same with incoming traffic filter rules, outgoing traffic filter rules are configured in different locations depending on the network type in use.

• For isolated networks, outgoing filter rules are applied on the network. Isolated networks have Egress rules tab on their detail page.

• For VPC networks, outgoing traffic is filtered through VPC Access Control Lists (ACLs). Traffic handling is determined by the ACL rules attached to each network tier within the VPC.

• For shared networks, outgoing filter rules are managed through security groups. By default egress traffic is allowed for shared network.

Below is the procedure for creating an egress rule on an isolated network

1. Log in to the UI as an administrator.

2. In the left navigation, choose Network.

3. In Select view, choose Guest networks, then click the Guest network you want.

4. To add an egress rule, click the Egress rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of instances in this guest network:

   

   • Source and Destination CIDR: (Add by CIDR only) To send traffic only to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
   • Protocol: The networking protocol that instances uses to send outgoing traffic. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
   • Start Port, End Port: (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
   • ICMP Type, ICMP Code: (ICMP only) The type of message and error code that are sent.

5. Click Add.

Public IP

Acquiring a New IP Address

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. Click the name of the network where you want to work with.
4. Click the Public IP Addresses tab.
5. Click Acquire New IP. The Acquire New IP window is displayed.
   
   Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.

Releasing an IP Address

When the last rule for an IP address is removed, you can release that IP address.

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. Click the name of the network where you want to work with.
4. Click Public IP Addresses.
5. Click the IP address you want to release.
6. Click the Release IP button.

Reserving a Public IP Address

When a public IP address is Free, you can reserve the public IP address. The public IP address can be reserved to the caller or other accounts.

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. Click Public IP Addresses. By default, it displays the Public IP Addresses in Allocate state.
4. Filter the Public IP Addresses by state ‘Free’
   
5. Click the Public IP address you want to reserve.
6. Click the Reserve IP button.
   
   The Reserve Public IP dialog is displayed.
7. In the drop-down list, select the Account Type (Account or Project), Domain, and Account or Project that you would like to reserve this Public IP to.
   
8. Click Submit button.

• Reserved Public IP Addresses can be acquired and used in isolated Networks or VPCs of the accounts which the Public IP Addresses are reserved to.
• Reserved Public IP Addresses will be considered as an used Public IP of the account and domain.

Releasing a Reserved Public IP Address

When a public IP address is Reserved, you can release the public IP address so that the public IP address is ready for use by other accounts.

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. Click Public IP Addresses. By default, it displays the Public IP Addresses in Allocate state.
4. Filter the Public IP Addresses by state ‘Reserved’
5. Click the Public IP address you want to release.
6. Click the Release IP button.
   
7. Click OK button.

IP Forwarding

IP forwarding is a network service that allows you to direct specific incoming traffic from a public IP address to a particular private IP address and vice versa.

IP forwarding in Zergaw CloudStack is categorized into two main services: Port Forwarding and NAT. Both rely on acquiring a public IP address and configuring the VR to translate and route traffic.

Port forwarding

Port forwarding is used to expose a specific service on a VM to the public internet. It maps a single or multiple public IP/port combination to a single or multiple private IP/port combination. For example, Allowing external access to SSH (port 22) or a web server (port 80) running on a VM without exposing any other ports.

To set up port forwarding:

1. Log in to the UI as an administrator.
2. In the left navigation bar, click Network.
3. Click the name of the guest network where the instances are running.
4. Choose an existing IP address or acquire a new IP address.
   Click the name of the IP address in the list.
5. Click the Port Forwarding tab.
6. Fill in the following:
   
   • Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
   • Private Port: The port on which the instance is listening for forwarded public traffic.
   • Protocol: The communication protocol in use between the two ports
7. Click Add.

NAT (Network Address Translation)

NAT is network feature that allows virtual machines in private networks to communicate with external networks, such as the internet, by translating private IP addresses to public IP addresses. Or it maps specific public IP address directly to a single VM, allowing inbound traffic to reach that VM.

Source NAT

Source NAT is automatically enabled on isolated networks and VPC tiers, translating outbound traffic from private IPs to a public IP so instances can access the internet.

You can change the source NAT ip address of a network by following the below procedure

1. Log in to the UI as an administrator.
2. In the left navigation bar, click Network.
3. Click the name of the guest network where the instances are running.
4. Click on the public IP addresses tab
5. Aquire a new public IP address or choose an existing one
6. Click on make source NAT button beside the public ip address to change the source NAT IP of the network
   
7. Click Add.

Static NAT

A static NAT rule maps a public IP address to the private IP address of an instance in order to allow Internet traffic into the instance. The public IP address always remains the same, which is why it is called static NAT.

Below is the procedure for configuring static NAT

If a Guest Instance is part of more than one network, static NAT rules will function only if they are defined on the default network.

1. Log in to the UI as an administrator.

2. In the left navigation, choose Network.

3. Click the name of the network where you want to work with.

4. Click Public IP Addresses.

5. Click the IP address you want to work with.

6. Click the Static NAT button.

   The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
   

7. If you are enabling static NAT, a dialog appears where you can choose the destination instance and click Apply.
   

IP Load Balancing

The user may choose to associate the same public IP for multiple guests. Zergaw CloudStack implements a TCP-level load balancer with the following policies.

• Round-robin
• Least connection
• Source IP

This is similar to port forwarding but the destination may be multiple IP addresses.

To configure load balancing the following step can be followed

1. Log in to the UI as an administrator.
2. In the left navigation bar, click Network.
3. Click the name of the guest network where the instances are running.
4. Choose an existing IP address or acquire a new IP address.
   Click the name of the IP address in the list.
5. Click the Load balancing tab.
6. Fill in the following:
   
   • Name: name to identify the load balancing rule
   • Public Port: The port on which the public IP is listening to forward traffic to private port.
   • Private Port: The port on which the instance is listening for forwarded public traffic.
   • Source CIDR list: the source CIDR list to allow traffic from; all other CIDRs will be blocked. Multiple entries must be separated by a single comma character (,). By default, all CIDRs are allowed.
   • Algorithm: the type of load balancing algorithum to use
   • Protocol: The communication protocol in use between the two ports
   • Autoscale: set to yes if you intend to use this load balancing rule with autoscaling instance group
7. Click Add.

VPN

Remote Access VPN

Zergaw CloudStack Account owners can create virtual private networks (VPN) to access their Instances. A virtual router is used to provide the service. Zergaw CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X, Linux and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN.

Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.

• Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
• Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.

Configuring Remote Access VPN

To set up VPN for the cloud:

1. Log in as a user or administrator to the UI.

2. In the left navigation, click Network.

3. Click the name of the network you want to work with.

4. Click Public IP Addresses.

5. Click one of the displayed IP address names.

6. Click the VPN Tab

7. Click the Enable Remote Access VPN.

   The IPsec key is displayed in a popup window.

Configuring Remote Access VPN in VPC

On enabling Remote Access VPN on a VPC, any VPN client present outside the VPC can access instances present in the VPC by using the Remote VPN connection. The VPN client can be present anywhere except inside the VPC on which the user enabled the Remote Access VPN service.

To enable VPN for a VPC:

1. Log in as a user or administrator to the UI.

2. In the left navigation, click Network.

3. In the Select view, select VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click on the VPC

5. In the VPC detail page, select Public IP Addresses.

   The IP Addresses page is displayed.

6. Click Source NAT IP address.

7. Click the Enable VPN button.

   Click OK to confirm. The IPsec key is displayed in a pop-up window.

Adding a Remote Access VPN User

Now, you need to add a VPN users.

1. Click the Source NAT IP.
2. Select the VPN tab.
3. Add the username and the corresponding password of the user you wanted to add.
4. Click Add.
5. Repeat the same steps to add the VPN users.

Using Remote Access VPN

Remote Access VPN connection to VPC or Guest Network to access Instances and applications. This section considers you have enabled Remote access VPN,

When connected to a VPC via VPN, the client have access to all Network Tiers.

Following information is required to confiture VPN client:

• Public IP: source NAT with VPN enabled.
• IPsec pre-shared key: Provide at the VPN activation.
• Username VPN account username.
• Password VPN account password.

Mac OSX

Mac OSX provide native IPsec VPN client.

1. Into System Preferences -> Network

2. Click “+” button and add a VPN:

   • Interface: VPN
   • VPN Type: L2TP over IPSec
   • Service Name: (ex: test-vpc1)

   

3. Configure L2TP over IPsec
   

4. Inside Authentication Settings…
   

5. Connect into VPN

   1. Click Apply to apply Network configuration changes.
   2. Click Connect to initiate VPN connection.
      

Microsoft Windows

Following instruction have been perform using Windows using Native VPN client.

1. Create network VPN connection
   
   
   
   
   
   
2. Configure VPN settings
   
   
   
   
   
3. Initiate VPN connection
   
   
   

Linux

Following instruction have been performed using Fedora Linux with KDE

Site-to-Site VPN

A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the Guest Instances by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. You can also establish a secure connection between two VPC setups or high availability zones in your environment. Having this facility eliminates the need to establish VPN connections to individual instances.

The difference from Remote VPN is that Site-to-site VPNs connects entire networks to each other, for example, connecting a branch office network to a company headquarters network. In a site-to-site VPN, hosts do not have VPN client software; they send and receive normal TCP/IP traffic through a VPN gateway.

Creating a VPN Gateway

To set up a Site-to-Site VPN connection, perform the following:

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network > VPC.
3. Select the VPC network and click on VPN Gateway.
4. Create a VPN gateway for the VPC that you created.
5. Create VPN connection from the VPC VPN gateway to the customer VPN
   gateway.

Creating and Updating a VPN Customer Gateway

A VPN customer gateway can be connected to only one VPN gateway at a time.

To add a VPN Customer Gateway:

1. Log in to the UI as an administrator.

2. In the left navigation, choose Network.

3. In the Select view, select VPN Customer Gateway.

4. Click Add VPN Customer Gateway.

   

   Provide the following information:

   • Name: A unique name for the VPN customer gateway you create.

   • Gateway: The IP address for the remote gateway.

   • CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.

   • IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other. The sequence cannot contain a newline or double-quote.

     The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.

   • IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.

     The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.

   • IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.

   • IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).

   • ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.

     The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.

   • ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.

   • Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.

     When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.

   • IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.

   • ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.

   • Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.

   • Force UDP Encapsulation of ESP Packets: Force Encapsulation for NAT traversal

5. Click OK.

Updating and Removing a VPN Customer Gateway

You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.

1. Log in to the UI as an administrator.
2. In the left navigation, choose Network.
3. In the Select view, select VPN Customer Gateway.
4. Select the VPN customer gateway you want to work with.
5. To modify the required parameters, click the Edit VPN Customer Gateway button
6. To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
7. Click OK.

Creating a VPN gateway for the VPC

1. Log in to the UI as an administrator or end user.

2. In the left navigation, choose Network.

3. In the Select view, select VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click on the VPC

5. Select VPN gateway.

   If you are creating the VPN gateway for the first time, click on Create site-to-site VPN gateway.

Creating a VPN Connection

Zergaw CloudStack VPC supports creating up to 8 VPN connections by default.

1. Log in to the UI as an administrator.

2. In the left navigation, choose Network.

3. In the Select view, select VPC.

   All the VPCs that you create for the account are listed in the page.

4. Click on the VPC

5. From the VPC detail page click on VPN connection.

6. Click site-to-site Create VPN Connection.

   The Create VPN Connection dialog is displayed:

   

7. Select the desired customer gateway.

8. Select Passive if you want to establish a connection between two VPC
   virtual routers.

   If you want to establish a connection between two VPC virtual routers, select Passive only on one of the VPC virtual routers, which waits for the other VPC virtual router to initiate the connection. Do not select Passive on the VPC virtual router that initiates the connection.

9. Click OK to confirm.

   Within a few moments, the VPN Connection is displayed.

   The following information on the VPN connection is displayed:

   • IP Address
   • Gateway
   • State
   • IPSec Preshared Key
   • IKE Policy
   • ESP Policy

Restarting and Removing a VPN Connection

1. Log in to the UI as an administrator.

2. In the left navigation, choose Network.

3. In the Select view, select VPC.

   All the VPCs that you have created for the account is listed in the page.

4. Click on the VPC

5. Click on VPN connection from the VPC detail page and Select the VPN connection you want to work with.

   The Details tab is displayed.

6. To remove a VPN connection, click the Delete VPN connection button
   

   To restart a VPN connection, click the Reset VPN connection button present in the Details tab.

VPC Peering

Site-to-Site VPN Connection Between VPC Networks

Zergaw CloudStack provides you with the ability to establish a site-to-site VPN connection between different VPCs. To achieve that, add a passive mode Site-to-Site VPN. With this functionality, users can deploy applications in multiple Availability Zones or VPCs, which can communicate with each other by using a secure Site-to-Site VPN Tunnel.

1. Create two VPCs. For example, VPC A and VPC B.

2. Create VPN gateways on both the VPCs you created.

3. Create VPN customer gateway for both the VPCs.

4. Enable a VPN connection on VPC A in passive mode.

   Ensure that the customer gateway is pointed to VPC B. The VPN connection is shown in the Disconnected state.

5. Enable a VPN connection on VPC B.

   Ensure that the customer gateway is pointed to VPC A. Because virtual router of VPC A, in this case, is in passive mode and is waiting for the virtual router of VPC B to initiate the connection, VPC B virtual router should not be in passive mode.

   The VPN connection is shown in the Disconnected state.

   Creating VPN connection on both the VPCs initiates a VPN connection. Wait for few seconds. The default is 30 seconds for both the VPN connections to show the Connected state.