Managing Networks and Traffic¶

Prerequisites¶

Ensure that vm-tools are running on guest VMs for adding or removing networks to work on VMware hypervisor.

Adding a Network¶

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

2. In the left navigation, click Instances.

3. Choose the VM that you want to work with.

4. Click the NICs tab.

5. Click Add network to VM.

   The Add network to VM dialog is displayed.

6. In the drop-down list, select the network that you would like to add this VM to.

   A new NIC is added for this network. You can view the following details in the NICs page:

   • ID
   • Network Name
   • Type
   • IP Address
   • Gateway
   • Netmask
   • Is default
   • CIDR (for IPv6)

Removing a Network¶

1. Log in to the CloudStack UI as an administrator or end user.
2. In the left navigation, click Instances.
3. Choose the VM that you want to work with.
4. Click the NICs tab.
5. Locate the NIC you want to remove.
6. Click Remove NIC button.
7. Click Yes to confirm.

Selecting the Default Network¶

1. Log in to the CloudStack UI as an administrator or end user.
2. In the left navigation, click Instances.
3. Choose the VM that you want to work with.
4. Click the NICs tab.
5. Locate the NIC you want to work with.
6. Click the Set default NIC button. .
7. Click Yes to confirm.

Guidelines¶

Before transferring to another network, ensure that no network rules (Firewall, Static NAT, Port Forwarding, and so on) exist on that portable IP.

Setting for CentOS¶

To use security groups on CentOS/RHEL/Fedora please enable bridge based filtering, ensure that default sysctl configuration file usually at /usr/lib/sysctl.d/00-system.conf set to following and run ‘sysctl -p’:

Limitations¶

The following are not supported for this feature:

• Two IP ranges with the same VLAN and different gateway or netmask in security group-enabled shared network.
• Two IP ranges with the same VLAN and different gateway or netmask in account-specific shared networks.
• Multiple VLAN ranges in security group-enabled shared network.
• Multiple VLAN ranges in account-specific shared networks.

Security groups must be enabled in the zone in order for this feature to be used.

Adding a Load Balancer Rule¶

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

2. In the left navigation, choose Network.

3. Click the name of the network where you want to load balance the traffic.

4. Click View IP Addresses.

5. Click the IP address for which you want to create the rule, then click the Configuration tab.

6. In the Load Balancing node of the diagram, click View All.

   In a Basic zone, you can also create a load balancing rule without acquiring or selecting an IP address. CloudStack internally assign an IP when you create the load balancing rule, which is listed in the IP Addresses page when the rule is created.

   To do that, select the name of the network, then click Add Load Balancer tab. Continue with #7.

7. Fill in the following:

   • Name: A name for the load balancer rule.
   • Public Port: The port receiving incoming traffic to be balanced.
   • Private Port: The port that the VMs will use to receive the traffic.
   • Algorithm: Choose the load balancing algorithm you want CloudStack to use. CloudStack supports a variety of well-known algorithms. If you are not familiar with these choices, you will find plenty of information about them on the Internet.
   • Stickiness: (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
   • AutoScale: Click Configure and complete the AutoScale configuration as explained in Configuring AutoScale.
   • Health Check: (Optional; NetScaler load balancers only) Click Configure and fill in the characteristics of the health check policy. See Health Checks for Load Balancer Rules.
     • Ping path (Optional): Sequence of destinations to which to send health check queries. Default: / (all).
     • Response time (Optional): How long to wait for a response from the health check (2 - 60 seconds). Default: 5 seconds.
     • Interval time (Optional): Amount of time between health checks (1 second - 5 minutes). Default value is set in the global configuration parameter lbrule_health check_time_interval.
     • Healthy threshold (Optional): Number of consecutive health check successes that are required before declaring an instance healthy. Default: 2.
     • Unhealthy threshold (Optional): Number of consecutive health check failures that are required before declaring an instance unhealthy. Default: 10.

8. Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.

   The new load balancer rule appears in the list. You can repeat these steps to add more load balancer rules for this IP address.

Sticky Session Policies for Load Balancer Rules¶

Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user’s session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of “stickiness” is also referred to as persistence or maintaining state.

Any load balancer rule defined in CloudStack can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie, application-generated cookie, or source-based. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. The cookie name can be specified by the administrator or automatically generated. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached.

For the most up to date list of available stickiness methods, see the CloudStack UI or call listNetworks and check the SupportedStickinessMethods capability.

Health Checks for Load Balancer Rules¶

(NetScaler load balancer only; requires NetScaler version 10.0)

Health checks are used in load-balanced applications to ensure that requests are forwarded only to running, available services. When creating a load balancer rule, you can specify a health check policy. This is in addition to specifying the stickiness policy, algorithm, and other load balancer rule options. You can configure one health check policy per load balancer rule.

Any load balancer rule defined on a NetScaler load balancer in CloudStack can have a health check policy. The policy consists of a ping path, thresholds to define “healthy” and “unhealthy” states, health check frequency, and timeout wait interval.

When a health check policy is in effect, the load balancer will stop forwarding requests to any resources that are found to be unhealthy. If the resource later becomes available again, the periodic health check will discover it, and the resource will once again be added to the pool of resources that can receive requests from the load balancer. At any given time, the most recent result of the health check is displayed in the UI. For any VM that is attached to a load balancer rule with a health check configured, the state will be shown as UP or DOWN in the UI depending on the result of the most recent health check.

You can delete or modify existing health check policies.

To configure how often the health check is performed by default, use the global configuration setting healthcheck.update.interval (default value is 600 seconds). You can override this value for an individual health check policy.

For details on how to set a health check policy using the UI, see Adding a Load Balancer Rule.

Prerequisites¶

Before you configure an AutoScale rule, consider the following:

• Ensure that the necessary template is prepared before configuring AutoScale. When a VM is deployed by using a template and when it comes up, the application should be up and running.

  Note

  If the application is not running, the NetScaler device considers the VM as ineffective and continues provisioning the VMs unconditionally until the resource limit is exhausted.

• Deploy the templates you prepared. Ensure that the applications come up on the first boot and is ready to take the traffic. Observe the time requires to deploy the template. Consider this time when you specify the quiet time while configuring AutoScale.

• The AutoScale feature supports the SNMP counters that can be used to define conditions for taking scale up or scale down actions. To monitor the SNMP-based counter, ensure that the SNMP agent is installed in the template used for creating the AutoScale VMs, and the SNMP operations work with the configured SNMP community and port by using standard SNMP managers. For example, see “Configuring SNMP Community String on a RHELServer” to configure SNMP on a RHEL machine.

• Ensure that the endpointe.url parameter present in the Global Settings is set to the Management Server API URL. For example, http://10.102.102.22:8080/client/api. In a multi-node Management Server deployment, use the virtual IP address configured in the load balancer for the management server’s cluster. Additionally, ensure that the NetScaler device has access to this IP address to provide AutoScale support.

  If you update the endpointe.url, disable the AutoScale functionality of the load balancer rules in the system, then enable them back to reflect the changes. For more information see Updating an AutoScale Configuration.

• If the API Key and Secret Key are regenerated for an AutoScale user, ensure that the AutoScale functionality of the load balancers that the user participates in are disabled and then enabled to reflect the configuration changes in the NetScaler.

• In an advanced Zone, ensure that at least one VM should be present before configuring a load balancer rule with AutoScale. Having one VM in the network ensures that the network is in implemented state for configuring AutoScale.

Configuration¶

Specify the following:

• Template: A template consists of a base OS image and application. A template is used to provision the new instance of an application on a scaleup action. When a VM is deployed from a template, the VM can start taking the traffic from the load balancer without any admin intervention. For example, if the VM is deployed for a Web service, it should have the Web server running, the database connected, and so on.

• Compute offering: A predefined set of virtual hardware attributes, including CPU speed, number of CPUs, and RAM size, that the user can select when creating a new virtual machine instance. Choose one of the compute offerings to be used while provisioning a VM instance as part of scaleup action.

• Min Instance: The minimum number of active VM instances that is assigned to a load balancing rule. The active VM instances are the application instances that are up and serving the traffic, and are being load balanced. This parameter ensures that a load balancing rule has at least the configured number of active VM instances are available to serve the traffic.

  Note

  If an application, such as SAP, running on a VM instance is down for some reason, the VM is then not counted as part of Min Instance parameter, and the AutoScale feature initiates a scaleup action if the number of active VM instances is below the configured value. Similarly, when an application instance comes up from its earlier down state, this application instance is counted as part of the active instance count and the AutoScale process initiates a scaledown action when the active instance count breaches the Max instance value.

• Max Instance: Maximum number of active VM instances that should be assigned toa load balancing rule. This parameter defines the upper limit of active VM instances that can be assigned to a load balancing rule.

  Specifying a large value for the maximum instance parameter might result in provisioning large number of VM instances, which in turn leads to a single load balancing rule exhausting the VM instances limit specified at the account or domain level.

  Note

  If an application, such as SAP, running on a VM instance is down for some reason, the VM is not counted as part of Max Instance parameter. So there may be scenarios where the number of VMs provisioned for a scaleup action might be more than the configured Max Instance value. Once the application instances in the VMs are up from an earlier down state, the AutoScale feature starts aligning to the configured Max Instance value.

Specify the following scale-up and scale-down policies:

• Duration: The duration, in seconds, for which the conditions you specify must be true to trigger a scaleup action. The conditions defined should hold true for the entire duration you specify for an AutoScale action to be invoked.
• Counter: The performance counters expose the state of the monitored instances. By default, CloudStack offers four performance counters: Three SNMP counters and one NetScaler counter. The SNMP counters are Linux User CPU, Linux System CPU, and Linux CPU Idle. The NetScaler counter is ResponseTime. The root administrator can add additional counters into CloudStack by using the CloudStack API.
• Operator: The following five relational operators are supported in AutoScale feature: Greater than, Less than, Less than or equal to, Greater than or equal to, and Equal to.
• Threshold: Threshold value to be used for the counter. Once the counter defined above breaches the threshold value, the AutoScale feature initiates a scaleup or scaledown action.
• Add: Click Add to add the condition.

Additionally, if you want to configure the advanced settings, click Show advanced settings, and specify the following:

• Polling interval: Frequency in which the conditions, combination of counter, operator and threshold, are to be evaluated before taking a scale up or down action. The default polling interval is 30 seconds.
• Quiet Time: This is the cool down period after an AutoScale action is initiated. The time includes the time taken to complete provisioning a VM instance from its template and the time taken by an application to be ready to serve traffic. This quiet time allows the fleet to come up to a stable state before any action can take place. The default is 300 seconds.
• Destroy VM Grace Period: The duration in seconds, after a scaledown action is initiated, to wait before the VM is destroyed as part of scaledown action. This is to ensure graceful close of any pending sessions or transactions being served by the VM marked for destroy. The default is 120 seconds.
• Security Groups: Security groups provide a way to isolate traffic to the VM instances. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM.
• Disk Offerings: A predefined set of disk size for primary data storage.
• SNMP Community: The SNMP community string to be used by the NetScaler device to query the configured counter value from the provisioned VM instances. Default is public.
• SNMP Port: The port number on which the SNMP agent that run on the provisioned VMs is listening. Default port is 161.
• User: This is the user that the NetScaler device use to invoke scaleup and scaledown API calls to the cloud. If no option is specified, the user who configures AutoScaling is applied. Specify another user name to override.
• Apply: Click Apply to create the AutoScale configuration.

Disabling and Enabling an AutoScale Configuration¶

If you want to perform any maintenance operation on the AutoScale VM instances, disable the AutoScale configuration. When the AutoScale configuration is disabled, no scaleup or scaledown action is performed. You can use this downtime for the maintenance activities. To disable the AutoScale configuration, click the Disable AutoScale button.

The button toggles between enable and disable, depending on whether AutoScale is currently enabled or not. After the maintenance operations are done, you can enable the AutoScale configuration back. To enable, open the AutoScale configuration page again, then click the Enable AutoScale button.

Updating an AutoScale Configuration¶

You can update the various parameters and add or delete the conditions in a scaleup or scaledown rule. Before you update an AutoScale configuration, ensure that you disable the AutoScale load balancer rule by clicking the Disable AutoScale button.

After you modify the required AutoScale parameters, click Apply. To apply the new AutoScale policies, open the AutoScale configuration page again, then click the Enable AutoScale button.

Runtime Considerations¶

• An administrator should not assign a VM to a load balancing rule which is configured for AutoScale.
• Before a VM provisioning is completed if NetScaler is shutdown or restarted, the provisioned VM cannot be a part of the load balancing rule though the intent was to assign it to a load balancing rule. To workaround, rename the AutoScale provisioned VMs based on the rule name or ID so at any point of time the VMs can be reconciled to its load balancing rule.
• Making API calls outside the context of AutoScale, such as destroyVM, on an autoscaled VM leaves the load balancing configuration in an inconsistent state. Though VM is destroyed from the load balancer rule, NetScaler continues to show the VM as a service assigned to a rule.

Components of GSLB¶

A typical GSLB environment is comprised of the following components:

• GSLB Site: In CloudStack terminology, GSLB sites are represented by zones that are mapped to data centers, each of which has various network appliances. Each GSLB site is managed by a NetScaler appliance that is local to that site. Each of these appliances treats its own site as the local site and all other sites, managed by other appliances, as remote sites. It is the central entity in a GSLB deployment, and is represented by a name and an IP address.
• GSLB Services: A GSLB service is typically represented by a load balancing or content switching virtual server. In a GSLB environment, you can have a local as well as remote GSLB services. A local GSLB service represents a local load balancing or content switching virtual server. A remote GSLB service is the one configured at one of the other sites in the GSLB setup. At each site in the GSLB setup, you can create one local GSLB service and any number of remote GSLB services.
• GSLB Virtual Servers: A GSLB virtual server refers to one or more GSLB services and balances traffic between traffic across the VMs in multiple zones by using the CloudStack functionality. It evaluates the configured GSLB methods or algorithms to select a GSLB service to which to send the client requests. One or more virtual servers from different zones are bound to the GSLB virtual server. GSLB virtual server does not have a public IP associated with it, instead it will have a FQDN DNS name.
• Load Balancing or Content Switching Virtual Servers: According to Citrix NetScaler terminology, a load balancing or content switching virtual server represents one or many servers on the local network. Clients send their requests to the load balancing or content switching virtual server’s virtual IP (VIP) address, and the virtual server balances the load across the local servers. After a GSLB virtual server selects a GSLB service representing either a local or a remote load balancing or content switching virtual server, the client sends the request to that virtual server’s VIP address.
• DNS VIPs: DNS virtual IP represents a load balancing DNS virtual server on the GSLB service provider. The DNS requests for domains for which the GSLB service provider is authoritative can be sent to a DNS VIP.
• Authoritative DNS: ADNS (Authoritative Domain Name Server) is a service that provides actual answer to DNS queries, such as web site IP address. In a GSLB environment, an ADNS service responds only to DNS requests for domains for which the GSLB service provider is authoritative. When an ADNS service is configured, the service provider owns that IP address and advertises it. When you create an ADNS service, the NetScaler responds to DNS queries on the configured ADNS service IP and port.

How Does GSLB Works in CloudStack?¶

Global server load balancing is used to manage the traffic flow to a web site hosted on two separate zones that ideally are in different geographic locations. The following is an illustration of how GLSB functionality is provided in CloudStack: An organization, xyztelco, has set up a public cloud that spans two zones, Zone-1 and Zone-2, across geographically separated data centers that are managed by CloudStack. Tenant-A of the cloud launches a highly available solution by using xyztelco cloud. For that purpose, they launch two instances each in both the zones: VM1 and VM2 in Zone-1 and VM5 and VM6 in Zone-2. Tenant-A acquires a public IP, IP-1 in Zone-1, and configures a load balancer rule to load balance the traffic between VM1 and VM2 instances. CloudStack orchestrates setting up a virtual server on the LB service provider in Zone-1. Virtual server 1 that is set up on the LB service provider in Zone-1 represents a publicly accessible virtual server that client reaches at IP-1. The client traffic to virtual server 1 at IP-1 will be load balanced across VM1 and VM2 instances.

Tenant-A acquires another public IP, IP-2 in Zone-2 and sets up a load balancer rule to load balance the traffic between VM5 and VM6 instances. Similarly in Zone-2, CloudStack orchestrates setting up a virtual server on the LB service provider. Virtual server 2 that is setup on the LB service provider in Zone-2 represents a publicly accessible virtual server that client reaches at IP-2. The client traffic that reaches virtual server 2 at IP-2 is load balanced across VM5 and VM6 instances. At this point Tenant-A has the service enabled in both the zones, but has no means to set up a disaster recovery plan if one of the zone fails. Additionally, there is no way for Tenant-A to load balance the traffic intelligently to one of the zones based on load, proximity and so on. The cloud administrator of xyztelco provisions a GSLB service provider to both the zones. A GSLB provider is typically an ADC that has the ability to act as an ADNS (Authoritative Domain Name Server) and has the mechanism to monitor health of virtual servers both at local and remote sites. The cloud admin enables GSLB as a service to the tenants that use zones 1 and 2.

Tenant-A wishes to leverage the GSLB service provided by the xyztelco cloud. Tenant-A configures a GSLB rule to load balance traffic across virtual server 1 at Zone-1 and virtual server 2 at Zone-2. The domain name is provided as A.xyztelco.com. CloudStack orchestrates setting up GSLB virtual server 1 on the GSLB service provider at Zone-1. CloudStack binds virtual server 1 of Zone-1 and virtual server 2 of Zone-2 to GLSB virtual server 1. GSLB virtual server 1 is configured to start monitoring the health of virtual server 1 and 2 in Zone-1. CloudStack will also orchestrate setting up GSLB virtual server 2 on GSLB service provider at Zone-2. CloudStack will bind virtual server 1 of Zone-1 and virtual server 2 of Zone-2 to GLSB virtual server 2. GSLB virtual server 2 is configured to start monitoring the health of virtual server 1 and 2. CloudStack will bind the domain A.xyztelco.com to both the GSLB virtual server 1 and 2. At this point, Tenant-A service will be globally reachable at A.xyztelco.com. The private DNS server for the domain xyztelcom.com is configured by the admin out-of-band to resolve the domain A.xyztelco.com to the GSLB providers at both the zones, which are configured as ADNS for the domain A.xyztelco.com. A client when sends a DNS request to resolve A.xyztelcom.com, will eventually get DNS delegation to the address of GSLB providers at zone 1 and 2. A client DNS request will be received by the GSLB provider. The GSLB provider, depending on the domain for which it needs to resolve, will pick up the GSLB virtual server associated with the domain. Depending on the health of the virtual servers being load balanced, DNS request for the domain will be resolved to the public IP associated with the selected virtual server.

Prerequisites and Guidelines¶

• The GSLB functionality is supported both Basic and Advanced zones.

• GSLB is added as a new network service.

• GSLB service provider can be added to a physical network in a zone.

• The admin is allowed to enable or disable GSLB functionality at region level.

• The admin is allowed to configure a zone as GSLB capable or enabled.

  A zone shall be considered as GSLB capable only if a GSLB service provider is provisioned in the zone.

• When users have VMs deployed in multiple availability zones which are GSLB enabled, they can use the GSLB functionality to load balance traffic across the VMs in multiple zones.

• The users can use GSLB to load balance across the VMs across zones in a region only if the admin has enabled GSLB in that region.

• The users can load balance traffic across the availability zones in the same region or different regions.

• The admin can configure DNS name for the entire cloud.

• The users can specify an unique name across the cloud for a globally load balanced service. The provided name is used as the domain name under the DNS name associated with the cloud.

  The user-provided name along with the admin-provided DNS name is used to produce a globally resolvable FQDN for the globally load balanced service of the user. For example, if the admin has configured xyztelco.com as the DNS name for the cloud, and user specifies ‘foo’ for the GSLB virtual service, then the FQDN name of the GSLB virtual service is foo.xyztelco.com.

• While setting up GSLB, users can select a load balancing method, such as round robin, for using across the zones that are part of GSLB.

• The user shall be able to set weight to zone-level virtual server. Weight shall be considered by the load balancing method for distributing the traffic.

• The GSLB functionality shall support session persistence, where series of client requests for particular domain name is sent to a virtual server on the same zone.

  Statistics is collected from each GSLB virtual server.

Enabling GSLB in NetScaler¶

In each zone, add GSLB-enabled NetScaler device for load balancing.

1. Log in as administrator to the CloudStack UI.

2. In the left navigation bar, click Infrastructure.

3. In Zones, click View More.

4. Choose the zone you want to work with.

5. Click the Physical Network tab, then click the name of the physical network.

6. In the Network Service Providers node of the diagram, click Configure.

   You might have to scroll down to see this.

7. Click NetScaler.

8. Click Add NetScaler device and provide the following:

   For NetScaler:

   • IP Address: The IP address of the SDX.
   • Username/Password: The authentication credentials to access the device. CloudStack uses these credentials to access the device.
   • Type: The type of device that is being added. It could be F5 Big Ip Load Balancer, NetScaler VPX, NetScaler MPX, or NetScaler SDX. For a comparison of the NetScaler types, see the CloudStack Administration Guide.
   • Public interface: Interface of device that is configured to be part of the public network.
   • Private interface: Interface of device that is configured to be part of the private network.
   • GSLB service: Select this option.
   • GSLB service Public IP: The public IP address of the NAT translator for a GSLB service that is on a private network.
   • GSLB service Private IP: The private IP of the GSLB service.
   • Number of Retries. Number of times to attempt a command on the device before considering the operation failed. Default is 2.
   • Capacity: The number of networks the device can handle.
   • Dedicated: When marked as dedicated, this device will be dedicated to a single account. When Dedicated is checked, the value in the Capacity field has no significance implicitly, its value is 1.

9. Click OK.

Adding a GSLB Rule¶

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

2. In the left navigation pane, click Region.

3. Select the region for which you want to create a GSLB rule.

4. In the Details tab, click View GSLB.

5. Click Add GSLB.

   The Add GSLB page is displayed as follows:

   

6. Specify the following:

   • Name: Name for the GSLB rule.
   • Description: (Optional) A short description of the GSLB rule that can be displayed to users.
   • GSLB Domain Name: A preferred domain name for the service.
   • Algorithm: (Optional) The algorithm to use to load balance the traffic across the zones. The options are Round Robin, Least Connection, and Proximity.
   • Service Type: The transport protocol to use for GSLB. The options are TCP and UDP.
   • Domain: (Optional) The domain for which you want to create the GSLB rule.
   • Account: (Optional) The account on which you want to apply the GSLB rule.

7. Click OK to confirm.

Assigning Load Balancing Rules to GSLB¶

1. Log in to the CloudStack UI as a domain administrator or user.
2. In the left navigation pane, click Region.
3. Select the region for which you want to create a GSLB rule.
4. In the Details tab, click View GSLB.
5. Select the desired GSLB.
6. Click view assigned load balancing.
7. Click assign more load balancing.
8. Select the load balancing rule you have created for the zone.
9. Click OK to confirm.

Prerequisites and Guidelines¶

Consider the following scenarios to apply egress firewall rules:

• Egress firewall rules are supported on Juniper SRX and virtual router.
• The egress firewall rules are not supported on shared networks.
• Allow the egress traffic from specified source CIDR. The Source CIDR is part of guest network CIDR.
• Allow the egress traffic with protocol TCP,UDP,ICMP, or ALL.
• Allow the egress traffic with protocol and destination port range. The port range is specified for TCP, UDP or for ICMP type and code.
• The default policy is Allow for the new network offerings, whereas on upgrade existing network offerings with firewall service providers will have the default egress policy Deny.

Configuring an Egress Firewall Rule¶

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

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 VM instances in this guest network:

   

   • 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 VMs 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.

Configuring the Default Egress Policy¶

The default egress policy for Isolated guest network is configured by using Network offering. Use the create network offering option to determine whether the default policy should be block or allow all the traffic to the public network from a guest network. Use this network offering to create the network. If no policy is specified, by default all the traffic is allowed from the guest network that you create by using this network offering.

You have two options: Allow and Deny.

Creating and Updating a VPN Customer Gateway¶

To add a VPN Customer Gateway:

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

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.

     Note

     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.

     Note

     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.

     Note

     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.

     Note

     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.

5. Click OK.

Creating a VPN gateway for the VPC¶

1. Log in to the CloudStack 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 the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

   For each tier, the following options are displayed:

   • Internal LB
   • Public LB IP
   • Static NAT
   • Virtual Machines
   • CIDR

   The following router information is displayed:

   • Private Gateways
   • Public IP Addresses
   • Site-to-Site VPNs
   • Network ACL Lists

5. Select Site-to-Site VPN.

   If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.

6. In the confirmation dialog, click Yes to confirm.

   Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.

   The following details are displayed in the VPN Gateway page:

   • IP Address
   • Account
   • Domain

Creating a VPN Connection¶

1. Log in to the CloudStack 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 create for the account are listed in the page.

4. Click the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

5. Click the Settings icon.

   For each tier, the following options are displayed:

   • Internal LB
   • Public LB IP
   • Static NAT
   • Virtual Machines
   • CIDR

   The following router information is displayed:

   • Private Gateways
   • Public IP Addresses
   • Site-to-Site VPNs
   • Network ACL Lists

6. Select Site-to-Site VPN.

   The Site-to-Site VPN page is displayed.

7. From the Select View drop-down, ensure that VPN Connection is selected.

8. Click Create VPN Connection.

   The Create VPN Connection dialog is displayed:

   

9. Select the desired customer gateway.

10. 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.

11. 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

Site-to-Site VPN Connection Between VPC Networks¶

CloudStack provides you with the ability to establish a site-to-site VPN connection between CloudStack virtual routers. 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.

This feature is supported on all the hypervisors.

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

   For more information, see “Configuring a Virtual Private Cloud”.

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

   For more information, see “Creating a VPN gateway for the VPC”.

3. Create VPN customer gateway for both the VPCs.

   For more information, see “Creating and Updating a VPN Customer Gateway”.

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

   For more information, see “Creating a VPN Connection”.

   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.

Restarting and Removing a VPN Connection¶

1. Log in to the CloudStack 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 the Configure button of the VPC to which you want to deploy the VMs.

   The VPC page is displayed where all the tiers you created are listed in a diagram.

5. Click the Settings icon.

   For each tier, the following options are displayed:

   • Internal LB
   • Public LB IP
   • Static NAT
   • Virtual Machines
   • CIDR

   The following router information is displayed:

   • Private Gateways
   • Public IP Addresses
   • Site-to-Site VPNs
   • Network ACL Lists

6. Select Site-to-Site VPN.

   The Site-to-Site VPN page is displayed.

7. From the Select View drop-down, ensure that VPN Connection is selected.

   All the VPN connections you created are displayed.

8. Select the VPN connection you want to work with.

   The Details tab is displayed.

9. 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.

Major Components of a VPC¶

A VPC is comprised of the following network components:

• VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
• Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
• Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
• Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
• Private Gateway: All the traffic to and from a private network routed to the VPC through the private gateway. For more information, see “Adding a Private Gateway to a VPC”.
• VPN Gateway: The VPC side of a VPN connection.
• Site-to-Site VPN Connection: A hardware-based VPN connection between your VPC and your datacenter, home network, or co-location facility. For more information, see “Setting Up a Site-to-Site VPN Connection”.
• Customer Gateway: The customer side of a VPN Connection. For more information, see “Creating and Updating a VPN Customer Gateway”.
• NAT Instance: An instance that provides Port Address Translation for instances to access the Internet via the public gateway. For more information, see “Enabling or Disabling Static NAT on a VPC”.
• Network ACL: Network ACL is a group of Network ACL items. Network ACL items are nothing but numbered rules that are evaluated in order, starting with the lowest numbered rule. These rules determine whether traffic is allowed in or out of any tier associated with the network ACL. For more information, see “Configuring Network Access Control List”.

Network Architecture in a VPC¶

In a VPC, the following four basic options of network architectures are present:

• VPC with a public gateway only
• VPC with public and private gateways
• VPC with public and private gateways and site-to-site VPN access
• VPC with a private gateway only and site-to-site VPN access

Connectivity Options for a VPC¶

You can connect your VPC to:

• The Internet through the public gateway.
• The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
• Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.

VPC Network Considerations¶

Consider the following before you create a VPC:

• A VPC, by default, is created in the enabled state.
• A VPC can be created in Advance zone only, and can’t belong to more than one zone at a time.
• The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
• The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
• Each tier should have an unique CIDR in the VPC. Ensure that the tier’s CIDR should be within the VPC CIDR range.
• A tier belongs to only one VPC.
• All network tiers inside the VPC should belong to the same account.
• When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
• A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
• The instances can only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
• Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
• The load balancing service can be supported by only one tier inside the VPC.
• If an IP address is assigned to a tier:
  • That IP can’t be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
  • That IP can’t be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
• Remote access VPN is not supported in VPC networks.

About Network ACL Lists¶

In CloudStack terminology, Network ACL is a group of Network ACL items. Network ACL items are nothing but numbered rules that are evaluated in order, starting with the lowest numbered rule. These rules determine whether traffic is allowed in or out of any tier associated with the network ACL. You need to add the Network ACL items to the Network ACL, then associate the Network ACL with a tier. Network ACL is associated with a VPC and can be assigned to multiple VPC tiers within a VPC. A Tier is associated with a Network ACL at all the times. Each tier can be associated with only one ACL.

The default Network ACL is used when no ACL is associated. Default behavior is all the incoming traffic is blocked and outgoing traffic is allowed from the tiers. Default network ACL cannot be removed or modified. Contents of the default Network ACL is:

Creating ACL Lists¶

1. Log in to the CloudStack 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 the Configure button of the VPC.

   For each tier, the following options are displayed:

   • Internal LB
   • Public LB IP
   • Static NAT
   • Virtual Machines
   • CIDR

   The following router information is displayed:

   • Private Gateways
   • Public IP Addresses
   • Site-to-Site VPNs
   • Network ACL Lists

5. Select Network ACL Lists.

   The following default rules are displayed in the Network ACLs page: default_allow, default_deny.

6. Click Add ACL Lists, and specify the following:

   • ACL List Name: A name for the ACL list.
   • Description: A short description of the ACL list that can be displayed to users.

Creating an ACL Rule¶

1. Log in to the CloudStack 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 the Configure button of the VPC.

5. Select Network ACL Lists.

   In addition to the custom ACL lists you have created, the following default rules are displayed in the Network ACLs page: default_allow, default_deny.

6. Select the desired ACL list.

7. Select the ACL List Rules tab.

   To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in the VPC.

   • Rule Number: The order in which the rules are evaluated.
   • CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or 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 incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
   • Action: What action to be taken. Allow traffic or block.
   • Protocol: The networking protocol that sources use to send traffic to the tier. 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. All supports all the traffic. Other option is Protocol Number.
   • Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
   • Protocol Number: The protocol number associated with IPv4 or IPv6. For more information, see Protocol Numbers.
   • ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
   • Traffic Type: The type of traffic: Incoming or outgoing.

8. Click Add. The ACL rule is added.

   You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Details tab.

Creating a Tier with Custom ACL List¶

1. Create a VPC.

2. Create a custom ACL list.

3. Add ACL rules to the ACL list.

4. Create a tier in the VPC.

   Select the desired ACL list while creating a tier.

5. Click OK.

Assigning a Custom ACL List to a Tier¶

1. Create a VPC.

2. Create a tier in the VPC.

3. Associate the tier with the default ACL rule.

4. Create a custom ACL list.

5. Add ACL rules to the ACL list.

6. Select the tier for which you want to assign the custom ACL.

7. Click the Replace ACL List icon.

   The Replace ACL List dialog is displayed.

8. Select the desired ACL list.

9. Click OK.

GUEST TRAFFIC for Private Gateway¶

When you provision Private Gateway with i.e. vlan id 1500, CloudStack will try to provision vlan interface with that vlan id on top of the physical interface which is defined for the selected physical network - i.e. if you defined “bond0” as the “traffic label” for the selected Physical Network, this means CloudStack will try to create “bond0.1500” vlan interface, and this will work just fine.

But in some cases, you might not be able to use current Guest Physical Network - i.e. if you are already running VXLAN as isolation method with i.e. bond0.150 being used as Traffic Label (vlan 150 caries all VXLAN tunnels) then CloudStack would try to provision “bond0.150.1500” interface, which will not work. In similar fashion, if you are using cloudbrX as Traffic Label for your Guest network (VLAN used as isolation method), this means CloudStack will try to provision “cloudbrX.1500” interface, which will also not work.

In cases described above, you would perhaps want to create additional Guest Physical Network, and specify bond0 as the Traffic Label (to comply with example values given above) - and here CloudStack will provision “bond0.1500” interface, which will work as expected.

In cases where you have 2 (or more) Guest Physical Networks, and you want one of them to be used for regular Guest Traffic (vlans, or vxlan tunnels), but you want another Guest Physical Network to be used for Private Gateway functionality (solution to the problem described above), then we need to make sure that we properly TAG both Guest Physical Networks and the needed Network Offerings - both the regular Network Offerings and also the hidden network offering that is used for Private Gateways (visible only inside DB), named “System-Private-Gateway-Network-Offering”.

For instruction on how to use tags with Physical networks and Network Offerings, please see “Tagging Guest Physical Network and Network Offerings”.

Source NAT on Private Gateway¶

You might want to deploy multiple VPCs with the same super CIDR and guest tier CIDR. Therefore, multiple guest VMs from different VPCs can have the same IPs to reach a enterprise data center through the private gateway. In such cases, a NAT service need to be configured on the private gateway to avoid IP conflicts. If Source NAT is enabled, the guest VMs in VPC reaches the enterprise network via private gateway IP address by using the NAT service.

The Source NAT service on a private gateway can be enabled while adding the private gateway. On deletion of a private gateway, source NAT rules specific to the private gateway are deleted.

To enable source NAT on existing private gateways, delete them and create afresh with source NAT.

ACL on Private Gateway¶

The traffic on the VPC private gateway is controlled by creating both ingress and egress network ACL rules. The ACLs contains both allow and deny rules. As per the rule, all the ingress traffic to the private gateway interface and all the egress traffic out from the private gateway interface are blocked.

You can change this default behaviour while creating a private gateway. Alternatively, you can do the following:

1. In a VPC, identify the Private Gateway you want to work with.

2. In the Private Gateway page, do either of the following:

   • Use the Quickview. See 3.
   • Use the Details tab. See 4 through .

3. In the Quickview of the selected Private Gateway, click Replace ACL, select the ACL rule, then click OK

4. Click the IP address of the Private Gateway you want to work with.

5. In the Detail tab, click the Replace ACL button.

   The Replace ACL dialog is displayed.

6. select the ACL rule, then click OK.

   Wait for few seconds. You can see that the new ACL rule is displayed in the Details page.

Creating a Static Route¶

CloudStack enables you to specify routing for the VPN connection you create. You can enter one or CIDR addresses to indicate which traffic is to be routed back to the gateway.

1. In a VPC, identify the Private Gateway you want to work with.

2. In the Private Gateway page, click the IP address of the Private Gateway you want to work with.

3. Select the Static Routes tab.

4. Specify the CIDR of destination network.

5. Click Add.

   Wait for few seconds until the new route is created.

Blacklisting Routes¶

CloudStack enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to blacklist in the blacklisted.routes global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is blacklisted for the zone.

Load Balancing Within a Tier (External LB)¶

A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a tier.

Load Balancing Across Tiers¶

CloudStack supports sharing workload across different tiers within your VPC. Assume that multiple tiers are set up in your environment, such as Web tier and Application tier. Traffic to each tier is balanced on the VPC virtual router on the public side, as explained in “Adding Load Balancing Rules on a VPC”. If you want the traffic coming from the Web tier to the Application tier to be balanced, use the internal load balancing feature offered by CloudStack.

Tagging Guest Physical Network and Network Offerings¶

In cases you have more than one Guest Physical Network, you might choose to use them for different purposes - i.e. to carry all “regular” VPC Guest Traffic (vlans/vxlans) on one Guest Physical Network, but use another Guest Physical Network for VPC Private Gateway (networks which are created as part of Private Gateway).

Example above would be accomplished by assigning different tags on these two Guest Physical Networks, and then tag proper Guest Network offerings in certain way, as explained later.

To edit tags in existing zone, for Guest Physical Networks, please do the following:

1. Log in to the CloudStack UI as an administrator.
2. Click on Infrastructure, then Zones, then particular Zone, then click on Physical Network tab, and from there select the correct Guest Network by clicking it, and again by clicking on “Guest / Configure” button.

1. In the presented screen, click on Edit button, and then you will be able to define tag for this particular Physical Network - set it to i.e. “guestvxlan”.

1. Repeat this step for second (and any additional) Guest Physical Networks, and make sure to use different tag for each of networks (as needed). Here we set it to “guestprivgtw”.

1. In this example above, we are setting tag “guestvxlan” for Guest Physical Network (bond0.150) that continues to carry VXLAN tunnels for VPCs, and we set tag “guestprivgtw” for Guest Physical Network (bond0) that will carry Private Gateway guest networks.

Next, we need to edit tags on existing Guest Network Offerings. Depending on CloudStack versions, you will need to edit database records directly.

General SQL query would look like following, but please use your own judgement to reflect your environment.

mysql> update network_offerings set tags="guestvxlan" where traffic_type="Guest";

This would set tag for all existing Guest Network Offers.

Now we want to put different tag on the hidden Network Offering that is used to provision Guest networks for Private Gateways.

mysql> update network_offerings set tags="guestprivgtw" where name="System-Private-Gateway-Network-Offering";

From now one, whenever you provision regular Guest Network (private tiers, part of VPC), these networks will be created on Guest Physical Network with tag “guestvxlan”, while Private Gateway Guest networks will be created on Guest Physical Network with tag “guestprivgtw”.

Anatomy of the Palo Alto Networks Firewall¶

• In ‘Network > Interfaces’ there is a list of physical interfaces as well as aggregated physical interfaces which are used for managing traffic in and out of the Palo Alto Networks Firewall device.
• In ‘Network > Zones’ there is a list of the different configuration zones. This implementation will use two zones; a public (defaults to ‘untrust’) and private (defaults to ‘trust’) zone.
• In ‘Network > Virtual Routers’ there is a list of VRs which handle traffic routing for the Palo Alto Firewall. We only use a single Virtual Router on the firewall and it is used to handle all the routing to the next network hop.
• In ‘Objects > Security Profile Groups’ there is a list of profiles which can be applied to firewall rules. These profiles are used to better understand the types of traffic that is flowing through your network. Configured when you add the firewall provider to CloudStack.
• In ‘Objects > Log Forwarding’ there is a list of profiles which can be applied to firewall rules. These profiles are used to better track the logs generated by the firewall. Configured when you add the firewall provider to CloudStack.
• In ‘Policies > Security’ there is a list of firewall rules that are currently configured. You will not need to modify this section because it will be completely automated by CloudStack, but you can review the firewall rules which have been created here.
• In ‘Policies > NAT’ there is a list of the different NAT rules. You will not need to modify this section because it will be completely automated by CloudStack, but you can review the different NAT rules that have been created here. Source NAT, Static NAT and Destination NAT (Port Forwarding) rules will show up in this list.

Configure the Public / Private Zones on the firewall¶

No manual configuration is required to setup these zones because CloudStack will configure them automatically when you add the Palo Alto Networks firewall device to CloudStack as a service provider. This implementation depends on two zones, one for the public side and one for the private side of the firewall.

• The public zone (defaults to ‘untrust’) will contain all of the public interfaces and public IPs.
• The private zone (defaults to ‘trust’) will contain all of the private interfaces and guest network gateways.

The NAT and firewall rules will be configured between these zones.

Configure the Public / Private Interfaces on the firewall¶

This implementation supports standard physical interfaces as well as grouped physical interfaces called aggregated interfaces. Both standard interfaces and aggregated interfaces are treated the same, so they can be used interchangeably. For this document, we will assume that we are using ‘ethernet1/1’ as the public interface and ‘ethernet1/2’ as the private interface. If aggregated interfaces where used, you would use something like ‘ae1’ and ‘ae2’ as the interfaces.

This implementation requires that the ‘Interface Type’ be set to ‘Layer3’ for both the public and private interfaces. If you want to be able to use the ‘Untagged’ VLAN tag for public traffic in CloudStack, you will need to enable support for it in the public ‘ethernet1/1’ interface (details below).

Steps to configure the Public Interface:

1. Log into Palo Alto Networks Firewall
2. Navigate to ‘Network > Interfaces’
3. Click on ‘ethernet1/1’ (for aggregated ethernet, it will probably be called ‘ae1’)
4. Select ‘Layer3’ from the ‘Interface Type’ list
5. Click ‘Advanced’
6. Check the ‘Untagged Subinterface’ check-box
7. Click ‘OK’

Steps to configure the Private Interface:

1. Click on ‘ethernet1/2’ (for aggregated ethernet, it will probably be called ‘ae2’)
2. Select ‘Layer3’ from the ‘Interface Type’ list
3. Click ‘OK’

Configure a Virtual Router on the firewall¶

The Virtual Router on the Palo Alto Networks Firewall is not to be confused with the Virtual Routers that CloudStack provisions. For this implementation, the Virtual Router on the Palo Alto Networks Firewall will ONLY handle the upstream routing from the Firewall to the next hop.

Steps to configure the Virtual Router:

1. Log into Palo Alto Networks Firewall
2. Navigate to ‘Network > Virtual Routers’
3. Select the ‘default’ Virtual Router or Add a new Virtual Router if there are none in the list
   • If you added a new Virtual Router, you will need to give it a ‘Name’
4. Navigate to ‘Static Routes > IPv4’
5. ‘Add’ a new static route
   • Name: next_hop (you can name it anything you want)
   • Destination: 0.0.0.0/0 (send all traffic to this route)
   • Interface: ethernet1/1 (or whatever you set your public interface as)
   • Next Hop: (specify the gateway IP for the next hop in your network)
   • Click ‘OK’
6. Click ‘OK’

Configure the default Public Subinterface¶

The current implementation of the Palo Alto Networks firewall integration uses CIDRs in the form of ‘w.x.y.z/32’ for the public IP addresses that CloudStack provisions. Because no broadcast or gateway IPs are in this single IP range, there is no way for the firewall to route the traffic for these IPs. To route the traffic for these IPs, we create a single subinterface on the public interface with an IP and a CIDR which encapsulates the CloudStack public IP range. This IP will need to be inside the subnet defined by the CloudStack public range netmask, but outside the CloudStack public IP range. The CIDR should reflect the same subnet defined by the CloudStack public range netmask. The name of the subinterface is determined by the VLAN configured for the public range in CloudStack.

To clarify this concept, we will use the following example.

Example CloudStack Public Range Configuration:

• Gateway: 172.30.0.1
• Netmask: 255.255.255.0
• IP Range: 172.30.0.100 - 172.30.0.199
• VLAN: Untagged

Configure the Public Subinterface:

1. Log into Palo Alto Networks Firewall
2. Navigate to ‘Network > Interfaces’
3. Select the ‘ethernet1/1’ line (not clicking on the name)
4. Click ‘Add Subinterface’ at the bottom of the window
5. Enter ‘Interface Name’: ‘ethernet1/1’ . ‘9999’
   • 9999 is used if the CloudStack public range VLAN is ‘Untagged’
   • If the CloudStack public range VLAN is tagged (eg: 333), then the name will reflect that tag
6. The ‘Tag’ is the VLAN tag that the traffic is sent to the next hop with, so set it accordingly. If you are passing ‘Untagged’ traffic from CloudStack to your next hop, leave it blank. If you want to pass tagged traffic from CloudStack, specify the tag.
7. Select ‘default’ from the ‘Config > Virtual Router’ drop-down (assuming that is what your virtual router is called)
8. Click the ‘IPv4’ tab
9. Select ‘Static’ from the ‘Type’ radio options
10. Click ‘Add’ in the ‘IP’ section
11. Enter ‘172.30.0.254/24’ in the new line
    • The IP can be any IP outside the CloudStack public IP range, but inside the CloudStack public range netmask (it can NOT be the gateway IP)
    • The subnet defined by the CIDR should match the CloudStack public range netmask
12. Click ‘OK’

Commit configuration on the Palo Alto Networks Firewall¶

In order for all the changes we just made to take effect, we need to commit the changes.

1. Click the ‘Commit’ link in the top right corner of the window
2. Click ‘OK’ in the commit window overlay
3. Click ‘Close’ to the resulting commit status window after the commit finishes

Add the Palo Alto Networks Firewall as a Service Provider¶

1. Navigate to ‘Infrastructure > Zones > ZONE_NAME > Physical Network > NETWORK_NAME (guest) > Configure; Network Service Providers’
2. Click on ‘Palo Alto’ in the list
3. Click ‘View Devices’
4. Click ‘Add Palo Alto Device’
5. Enter your configuration in the overlay. This example will reflect the details previously used in this guide.
   • IP Address: (the IP of the Palo Alto Networks Firewall)
   • Username: (the admin username for the firewall)
   • Password: (the admin password for the firewall)
   • Type: Palo Alto Firewall
   • Public Interface: ethernet1/1 (use what you setup earlier as the public interface if it is different from my examples)
   • Private Interface: ethernet1/2 (use what you setup earlier as the private interface if it is different from my examples)
   • Number of Retries: 2 (the default is fine)
   • Timeout: 300 (the default is fine)
   • Public Network: untrust (this is the public zone on the firewall and did not need to be configured)
   • Private Network: trust (this is the private zone on the firewall and did not need to be configured)
   • Virtual Router: default (this is the name of the Virtual Router we setup on the firewall)
   • Palo Alto Threat Profile: (not required. name of the ‘Security Profile Groups’ to apply. more details in the ‘Additional Features’ section)
   • Palo Alto Log Profile: (not required. name of the ‘Log Forwarding’ profile to apply. more details in the ‘Additional Features’ section)
   • Capacity: (not required)
   • Dedicated: (not required)
6. Click ‘OK’
7. Click on ‘Palo Alto’ in the breadcrumbs to go back one screen.
8. Click on ‘Enable Provider’

Add a Network Service Offering to use the new Provider¶

There are 6 ‘Supported Services’ that need to be configured in the network service offering for this functionality. They are DHCP, DNS, Firewall, Source NAT, Static NAT and Port Forwarding. For the other settings, there are probably additional configurations which will work, but I will just document a common case.

1. Navigate to ‘Service Offerings’
2. In the drop-down at the top, select ‘Network Offerings’
3. Click ‘Add Network Offering’
   • Name: (name it whatever you want)
   • Description: (again, can be whatever you want)
   • Guest Type: Isolated
   • Supported Services:
     • DHCP: Provided by ‘VirtualRouter’
     • DNS: Provided by ‘VirtualRouter’
     • Firewall: Provided by ‘PaloAlto’
     • Source NAT: Provided by ‘PaloAlto’
     • Static NAT: Provided by ‘PaloAlto’
     • Port Forwarding: Provided by ‘PaloAlto’
   • System Offering for Router: System Offering For Software Router
   • Supported Source NAT Type: Per account (this is the only supported option)
   • Default egress policy: (both ‘Allow’ and ‘Deny’ are supported)
4. Click ‘OK’
5. Click on the newly created service offering
6. Click ‘Enable network offering’

When adding networks in CloudStack, select this network offering to use the Palo Alto Networks firewall.

Palo Alto Networks Threat Profile¶

This feature allows you to specify a ‘Security Profile Group’ to be applied to all of the firewall rules which are created on the Palo Alto Networks firewall device.

To create a ‘Security Profile Group’ on the Palo Alto Networks firewall, do the following:

1. Log into the Palo Alto Networks firewall
2. Navigate to ‘Objects > Security Profile Groups’
3. Click ‘Add’ at the bottom of the page to add a new group
4. Give the group a Name and specify the profiles you would like to include in the group
5. Click ‘OK’
6. Click the ‘Commit’ link in the top right of the screen and follow the on screen instructions

Once you have created a profile, you can reference it by Name in the ‘Palo Alto Threat Profile’ field in the ‘Add the Palo Alto Networks Firewall as a Service Provider’ step.

Palo Alto Networks Log Forwarding Profile¶

This feature allows you to specify a ‘Log Forwarding’ profile to better manage where the firewall logs are sent to. This is helpful for keeping track of issues that can arise on the firewall.

To create a ‘Log Forwarding’ profile on the Palo Alto Networks Firewall, do the following:

1. Log into the Palo Alto Networks firewall
2. Navigate to ‘Objects > Log Forwarding’
3. Click ‘Add’ at the bottom of the page to add a new profile
4. Give the profile a Name and specify the details you want for the traffic and threat settings
5. Click ‘OK’
6. Click the ‘Commit’ link in the top right of the screen and follow the on screen instructions

Once you have created a profile, you can reference it by Name in the ‘Palo Alto Log Profile’ field in the ‘Add the Palo Alto Networks Firewall as a Service Provider’ step.