vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[CHANGE LOG](https://cloud.ibm.com/docs/fortigate-10g?topic=fortigate-10g-ibm-cloud-ip-rangescloud-infrastructure-jul2522)

To provision and reload classic Virtual Servers and classic Bare Metal Servers, the following private service networks must be allowed through your gateway appliances and firewalls.

Be sure to configure rules and verify routes for the service networks listed in the table below for dal10, wdc04, and the location of your server.

Additionally, complete the following steps:



* Allow and route the following service networks to the BCR on your gateway appliance or firewall for all Bare Metal and Virtual Server provisions and reloads: 10.0.64.0/19, 10.200.80.0/20, 161.26.13.0/24, 161.26.96.0/22, 166.9.12.0/23, 166.9.48.0/24, 166.9.50.0/24, 166.9.228.0/24, 166.9.250.192/27, 10.3.160.0/20, 10.201.0.0/20, 161.26.92.0/22, 161.26.132.0/22, 166.9.20.0/23, 166.9.231.0/24.
* For RHEL servers, ensure the entire 161.26.0.0/16 is allowed and routed properly to the BCR. Add any additional datacenter service networks that are mentioned in the RHEL section near the bottom of the page.
* Allow traffic between the service networks and your server in both directions.
* By default, all classic servers and classic gateway and firewall devices are configured with a static route for the 10.0.0.0/8, 161.26.0.0/16 and 166.8.0.0/14 networks to the Back-end Customer Router (BCR). If you configure overlapping routes with those subnets, validate that you have also configured PBR or a similar service. Otherwise, consider using different IP space that doesn't overlap with our service networks for your VPNs or tunnels.
When you permit traffic between members of a security group, as resources are added or deleted from the security group, you don't have to set up individual permissions between each current member and each new member of a security group.

For example, say you have host A and host B in a security group, and you add a new host C. Normally, you would have to perform maintainance to allow host A and host B to send traffic to and from host C after you add host C to the security group.

To make this process easier, you can define a policy in which you allow all traffic as long as it's from another member of your group. Then as you add or remove members from a group, the policy automatically changes to allow members of the group to send traffic between each other.

The following are UI instructions for defining rules in a security group to allow all traffic between members of that security group:



1. From your browser, open the [IBM Cloud console](https://cloud.ibm.com/login).
2. Select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg), then click VPC Infrastructure.
3. Click Security groups.
4. In the Security groups, select the security group object that you want to modify.
5. Click the Create + button in the upper right of the Inbound rules table. A Create inbound rule window appears.
6. In the Protocol section, select ALL.
7. In the Source type section, select Security group.
8. Click Create to apply these changes.









 Related links 

These links provide additional information about IBM Cloud Security Groups for VPC:



* [Security Groups CLI reference](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencesecurity-groups-cli-ref)
network_type = "ext"
network_name = module.ibm_vmware_solutions_shared_instance.default_gateway_network

original_address = "${vcd_network_routed.tutorial_network.gateway}/24"
translated_address = module.ibm_vmware_solutions_shared_instance.default_external_network_ip
}
Show more





 Create a firewall rule to access the IBM Cloud private network 

You can create rules to allow or deny traffic, this section creates a rule to allow traffic from the VDC network to the IBM Cloud private network with no additional restrictions. This will enable your virtual machines to access other IBM Cloud services, such as AI, cloud databases, storage without going over the Internet.

Zoom

![Access to the IBM Cloud private network](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution58-vmware-solutions-getting-started/ibm-cloud.svg)

Access to the IBM Cloud private network

resource "vcd_nsxv_firewall_rule" "rule_ibm_private" {
edge_gateway = module.ibm_vmware_solutions_shared_instance.edge_gateway_name
name = "${vcd_network_routed.tutorial_network.name}-IBM-Private"

logging_enabled = "false"
action = "accept"

source {
org_networks = [vcd_network_routed.tutorial_network.name]
}

destination {
gateway_interfaces = [module.ibm_vmware_solutions_shared_instance.external_networks_2]
}

service {
protocol = "any"
}
}

resource "vcd_nsxv_snat" "rule_ibm_private" {
edge_gateway = module.ibm_vmware_solutions_shared_instance.edge_gateway_name
network_type = "ext"
Known limitations with Hardware Firewall 

There are some limitations to know about when working with your Hardware Firewall.

A Hardware Firewall cannot be deployed to a server on a VLAN that meets any of the following criteria.



*  Is currently associated with a Network Gateway, Hardware Firewall, or FortiGate Security Appliance.
*  Contains 30 or more servers.
*  Has a primary subnet that is larger than a /28.
*  Contains a bare-metal server hosting a gateway, such as a Juniper vSRX or VRA, as these servers are deployed on a transit VLAN.



In these instances, a new VLAN must be established for the Firewall or another product must be selected.

Further limitations for the Hardware Firewall include:



*  Portable subnets are not protected
*  Not available for 10Gb servers
*  Maximum of 79 firewall rules per Hardware Firewall
*  Incompatible with Windows Network Load Balancing (NLB) due to the way ARP is processed
*  The rule destination subnet is limited to the public IP of the protected server.
*  The VLAN for the primary public IP that is protected by the hardware firewall cannot be associated or routed through another gateway, such as a Juniper vSRX or VRA.
Getting permitted network 'ffffffff-f7c9-49ff-a8ca-000000000000' for zone 'example.com:f7f40364-a5e6-48f7-9fc9-387434c579ae' ...
OK

Name vpc-gen1-for-pdns-e2e-test01-do-not-delete
ID ffffffff-f7c9-49ff-a8ca-000000000000
Type vpc
VPC_CRN crn:v1:bluemix:public:is:us-south:a/bcf1865e991345daf4d5f24ea90a5497::vpc:ffffffff-f7c9-49ff-a8ca-000000000000
State ACTIVE
Created On 2020-04-10 10:06:24.99659547 +0000 UTC
Modified On 2020-04-10 10:06:24.99659547 +0000 UTC





 Listing permitted networks 

Use ibmcloud dns permitted-networks followed by the zone ID to list all permitted networks.

$ ibmcloud dns permitted-networks $DNS_ZONE_ID
Listing permitted networks for zone 'example.com:f7f40364-a5e6-48f7-9fc9-387434c579ae' ...
OK

Name ID Type VPC_CRN State
vpc-gen1-for-pdns-e2e-test01-do-not-delete ffffffff-f7c9-49ff-a8ca-000000000000 vpc crn:v1:bluemix:public:is:us-south:a/bcf1865e991345daf4d5f24ea90a5497::vpc:ffffffff-f7c9-49ff-a8ca-000000000000 ACTIVE





 Removing a permitted network
Leveraging context-based restrictions to secure your resources 

This tutorial walks you through how to use context-based restrictions as an extra layer of protection to your resources. By completing this tutorial, you learn how to create network zones and rules that define access restrictions to specific resources based on context in addition to IAM identity. For more information, see [What are context-based restrictions?](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis)

The tutorial uses a fictitious account owner named Xander. Xander previously set up access for managers that need the administrator role on account management services by using IAM policies.

Xander trusts his team to manage their personal and service credentials properly, but he wants to make sure they are protected even if credentials are mismanaged. Because Xander knows the IP addresses that the team uses, Xander can restrict access to the access management service based on the network location of the access requests. This way, access policy creation is restricted to the IP addresses he defines. Since both IAM access and context-based restrictions must allow access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials.



 Before you begin 

Set up Activity Tracker to monitor your enabled and report-only rules. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).





 Step 1: Create a network zone 

First, create a new network zone for the team.



1. In the IBM Cloud console, click Manage > Context-based restrictions
2. Go to Network zones and then click Create.
3. Name the network zone management-team-zone
4. Enter the IP addresses the team must use:



1. Team members in Austin use the following IP addresses: 4.4.4.1-4.4.4.99
2. An Austin team member in another building uses the following subnet: 204.17.5.0/24
3. A remote team member uses the following IP address: 3.3.3.56



5. Click Next.
6.
In the [Access control lists for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/acl), click New access control list.
3. Give your ACL a name and choose the VPC and resource group that your subnets are in.
4. In the Rules section, delete the default inbound rule and outbound rule that allow all inbound and outbound traffic.
5. In the Inbound rules section, create the following rules by clicking Create.

ACL rules are applied to traffic in a specific order. If you must create custom rules to allow other traffic to or from your worker nodes on this subnet, be sure to set the custom rules' Priority before the final rule that denies all traffic. If you add a rule after the deny rule, your rule is ignored, because the packet matches the deny rule and is blocked and removed before it can reach your rule. Note that these steps outline the minimum ACL rules that are required for basic cluster functionality. You might need to create additional ACL rules based on your use case.



Table 4. Required inbound rules

 Rule purpose Allow/Deny Protocol Source IP or CIDR Source Port Destination IP or CIDR Destination Port Priority 

 Allow worker nodes to be created in your cluster. Allow ALL 161.26.0.0/16 <br><br> * <br><br><br> Any <br><br> * <br><br><br> Set to top 
 Allow worker nodes to communicate with other IBM Cloud services that support private cloud service endpoints, and in clusters that run Kubernetes version 1.19 or earlier, with the cluster master through the private cloud service endpoint. Allow ALL 166.8.0.0/14 <br><br> * <br><br><br> Any <br><br> * <br><br><br> After 1 
 Multizone clusters: Allow worker nodes in one subnet to communicate with the worker nodes in other subnets within the cluster. Create one rule for each subnet that you want to connect to.
IP Table Rules 

To allow the enforcement of iptables rules on your destination, you must have the Restrict network access option checked under the Network Security panel of your destination. At that point you can add the rules you want enforced, such as: 192.0.0.1 9000 (single IP and port), 192.0.0.1-192.0.0.5 5000:5005 (range of IPs and range of ports), or any combination of these rules. Please see [Configuring Network Security](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-add-destdest-network-security) for more information.

If you are creating your private destinations with cURL, you could use a command like:

curl "https://sgmanager.us-south.securegateway.cloud.ibm.com/v1/sgconfig/<gateway_id>/destinations" -H "Authorization: Bearer <security_token>" -H "Content-type: application/json" -d '{"desc":"My Private Destination","ip":"1.1.1.1","port":8000,"private":true}'

Once your private destination is created, you can add IP table rules with commands like:

curl -X PUT "https://sgmanager.us-south.securegateway.cloud.ibm.com/v1/sgconfig/<gateway_id>/destinations/<destination_id>/ipTableRule" -H "Authorization: Bearer <security_token>" -H "Content-type: application/json" -d '{"src":"192.0.0.1","spt":"9000"}' -k

and
[CHANGE LOG](https://cloud.ibm.com/docs/fortigate-1g?topic=cloud-infrastructure-ibm-cloud-ip-rangescloud-infrastructure-jul2522)

To provision and reload classic Virtual Servers and classic Bare Metal Servers, the following private service networks must be allowed through your gateway appliances and firewalls.

Be sure to configure rules and verify routes for the service networks listed in the table below for dal10, wdc04, and the location of your server.

Additionally, complete the following steps:



* Allow and route the following service networks to the BCR on your gateway appliance or firewall for all Bare Metal and Virtual Server provisions and reloads: 10.0.64.0/19, 10.200.80.0/20, 161.26.13.0/24, 161.26.96.0/22, 166.9.12.0/23, 166.9.48.0/24, 166.9.50.0/24, 166.9.228.0/24, 166.9.250.192/27, 10.3.160.0/20, 10.201.0.0/20, 161.26.92.0/22, 161.26.132.0/22, 166.9.20.0/23, 166.9.231.0/24.
* For RHEL servers, ensure the entire 161.26.0.0/16 is allowed and routed properly to the BCR. Add any additional datacenter service networks that are mentioned in the RHEL section near the bottom of the page.
* Allow traffic between the service networks and your server in both directions.
* By default, all classic servers and classic gateway and firewall devices are configured with a static route for the 10.0.0.0/8, 161.26.0.0/16 and 166.8.0.0/14 networks to the Back-end Customer Router (BCR). If you configure overlapping routes with those subnets, validate that you have also configured PBR or a similar service. Otherwise, consider using different IP space that doesn't overlap with our service networks for your VPNs or tunnels.
* CLI







 Protecting resources with context-based restrictions 

Context-based restrictions give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on the context of access requests. Access to Transit Gateway resources can be controlled with context-based restrictions and identity and access management policies.

These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection. Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure. Since both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials. For more information, see [What are context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis).

A user must have the Administrator role on the Transit Gateway service to create, update, or delete rules. And a user must have either the Editor or Administrator role on the Context-based restrictions service to create, update, or delete network zones.

Any IBM Cloud Activity Tracker or audit log events that are generated will come from the context-based restrictions service, and not Transit Gateway. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).

To get started protecting your Transit Gateway with context-based restrictions, see the tutorial for [Leveraging context-based restrictions to secure your resources](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-tutorial).



 Limitations 

Context-based restrictions protect only the actions associated with the [Transit Gateway API](https://cloud.ibm.com/apidocs/transit-gateway). Actions associated with the following platform APIs are not protected by context-based restrictions. Reference the API docs for the specific action IDs.



* [Resource Instance APIs](https://cloud.ibm.com/apidocs/resource-controller/resource-controllerlist-resource-instances)
Go to Manage > Context-based restrictions in the IBM Cloud® console.
2. Select Rules.
3. Click Create.
4. Select Specific APIs and then select Data plane. Any other selection results in an error.

Cloud Databases does not currently support Control plane as an option.
5. Click Next.
6. Scope the rule to All resources or Specific resources. For more information, see [Protecting Cloud Databases resources](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cbrcbr-overview-protect-services).
7. Click Continue.
8. Define the allowed endpoint types.



* Keep the toggle set to No to allow all endpoint types.
* Set the toggle to Yes to allow only specific endpoint types, then choose from the list.



9. Select a network zone or zones that you have already created, or create a new network zone by clicking Create.

Contexts define from where your resources can be accessed, effectively linking your network zone to your rule.
10. Click Add to add your configuration to the summary.
11. Click Next.
12. Name your rule.
13. Select how you want to enforce the rule.

Report-only is not available for Cloud Databases.







 Creating rules in the CLI 

To create rules in the CLI, [install the context-based restrictions CLI plug-in](https://cloud.ibm.com/docs/account?topic=account-cbr-plugin).

To create a rule in the CLI, you need the appropriate Cloud Databases service_name:



* databases-for-etcd
* databases-for-elasticsearch
* databases-for-mongodb
* databases-for-postgresql
* databases-for-redis
* messages-for-rabbitmq
* databases-for-cassandra
* databases-for-enterprisedb
* database-for-mysql



Create a rule by using a command like:
For HA, a Hardware Firewall (High Availability) or FortiGate Security Appliance (High Availability) is required. The Network Gateway product also has an HA option with firewall capabilities.
* I am running a hypervisor on an IBM Cloud server. Will the Hardware Firewall protect the Virtual Machines running on my hypervisor?

No. Portable IPs are used for the VMs in a hypervisor environment and portable IPs are not protected by the hardware firewall. A FortiGate Security Appliance is recommended.
* What are the grayed out ports in my Windows Firewall?

IBM Cloud offers many different services that you can utilize with your server including Evault, SNMP and Nagios monitoring. These services require that our internal systems communicate with your server to some degree. The grayed out ports you see in the Exceptions list are ports open on the internal network port only. They are still blocked on the public (internet) network connection. Since the internal network is a secured network having these ports open is considered secure.

These ports generally cannot be modified; however, if you reset the firewall rules, it will clear them from the Exceptions list. Please beware that resetting the firewall rules may have an adverse affect not only on these additional services but also could cause other issues as well with your server depending on its current configuration.
* What Hardware Firewall options are available for 10Gbps servers?

FSA 10G is the only option to support 10Gbps servers for both public and private traffic. If 10Gbps is only required on the private network (for database, backup, storage, etc), then customers can request a downgrade of only their public uplinks and order any of the Hardware Firewall products.
* What IP ranges do I allow through the firewall?

For the list of IP addresses and IP ranges to allow through the firewall, go [here](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=cloud-infrastructure-ibm-cloud-ip-ranges).
* What VPN options are included with each firewall product?

Not all firewalls offer VPN and not all VPN options are the same. The general options for VPN are:
You can configure the security group to define the inbound and outbound traffic that is allowed for the instance. For example, after you configure ACL rules for the subnet based on your company's security policies, you can further restrict traffic for specific instances depending on their workloads.

To configure the security group:



1. In the navigation pane, click Compute > Virtual server instances.
2. Click your instance to view its details.
3. In the Network interfaces section, click the name of the security group.
4. On the Rules tab of the security group details page, click Create to configure inbound and outbound rules that define what type of traffic is allowed to and from the instance. For each rule, specify the following information:



* Select the protocols and ports to which the rule applies.
* Specify a CIDR block or IP address for the permitted traffic. Alternatively, you can specify a security group in the same VPC to allow traffic to or from all instances that are attached to the selected security group.



Tips:



* All rules are evaluated, regardless of the order in which they're added.
* Rules are stateful, which means that return traffic in response to allowed traffic is automatically permitted. For example, you created a rule that allows inbound TCP traffic on port 80. That rule also allows replying outbound TCP traffic on port 80 back to the originating host, without the need for another rule.
* For Windows images, make sure that the security group that is associated with the instance allows inbound and outbound Remote Desktop Protocol traffic (TCP port 3389).
* If your z/OS virtual server instance is created by using the z/OS dev and test stock image, you can refer to the [Reserved configurations](https://www.ibm.com/docs/en/wazi-aas/1.0.0?topic=vpc-configurations-in-zos-stock-images) table when adding additional ports to the security group of your z/OS virtual server instance.



5. Optional: To view interfaces that are attached to the security group, click Attached resources tab and review the Attached interfaces section.
6.
On the return trip instead of firewall-router in zone 2 (same zone) now firewall-router in zone 1 will be used.



1. Apply the all_firewall_asym layer:

./apply.sh all_firewall_asym_tf
2. Run the test suite.

Your expected results are: all tests PASSED, run them in parallel:

pytest -n 10 -m curl



All traffic between VPCs is now routed through the firewall-routers.







 Step 2: High Performance High Availability (HA) Firewall-Router 

To prevent a firewall-router from becoming the performance bottleneck or a single point of failure it is possible to add a VPC Network Load Balancer to distribute traffic to the zonal firewall-routers to create a Highly Available, HA, firewall-router. Check your firewall-router documentation to verify it supports this architecture.

Zoom

![High Availability Firewall](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-ha-firewall.svg)

High Availability Firewall

This diagram shows a single zone with a Network Load Balancer (NLB) configured in route mode fronting two firewall-routers. To see this constructed it is required to change the configuration and apply again.



1. Change these two variables in config_tf/terraform.tfvars:

firewall_nlb = true
number_of_firewalls_per_zone = 2

This change results in the IP address of the firewall-router changing from the firewall-router instance used earlier to the IP address of the NLB. The IP address change need to be applied to a number of VPC route table routes in the transit and spoke VPCs. It is best to apply all of the layers previously applied:
2.