vania-janet/multiturn-rag-retrieval-data huggingface dataset:
set security firewall name APP-TO-TUNNEL rule 200 icmp group icmpgrp
set security firewall name APP-TO-TUNNEL rule 200 action accept
commit

set security firewall name TUNNEL-TO-APP default-action drop
set security firewall name TUNNEL-TO-APP default-log

set security firewall name TUNNEL-TO-APP rule 100 action accept
set security firewall name TUNNEL-TO-APP rule 100 protocol tcp
set security firewall name TUNNEL-TO-APP rule 100 destination port tcpports

set security firewall name TUNNEL-TO-APP rule 200 protocol icmp
set security firewall name TUNNEL-TO-APP rule 200 icmp group icmpgrp
set security firewall name TUNNEL-TO-APP rule 200 action accept
commit
3. Create Zone for tunnel and associate firewalls for traffic initiated in either zone.

set security zone-policy zone TUNNEL description "GRE Tunnel"
set security zone-policy zone TUNNEL default-action drop
set security zone-policy zone TUNNEL interface tun0

set security zone-policy zone TUNNEL to APP firewall TUNNEL-TO-APP
set security zone-policy zone APP to TUNNEL firewall APP-TO-TUNNEL
commit
4. To validate the firewalls and routing at both ends are configured correctly and are now allowing ICMP and TCP traffic ping the gateway address of the remote subnet, first from the VRA command line and if successful then by logging into the VSI.

ping <Remote Subnet Gateway IP>
ssh root@<VSI Private IP>
ping <Remote Subnet Gateway IP>
5. If the ping from the VRA command line fails, validate that a ping reply is seen in response to a ping request on the tunnel interface.

monitor interface tunnel tun0 traffic

No response indicates an issue with the firewall rules or routing at the data center. If a reply is seen in the monitor output, but the ping command times out, check the configuration of the local VRA firewall rules.
6. If the ping from the VSI fails, this indicates an issue with the VRA firewall rules, routing in the VRA or VSI configuration.
The rule has been enforced and, based on how you tried to access the registry, the access has been denied. The reason is that rule allows access from a specific VPC only. The Cloud Shell environment and its IP address, as documented in the logs in the requestData->environment fields, differ. Therefore, the request is denied.



When working with the Activity Tracker logs, you can utilize query strings like the following to easily find the relevant log records:



* When in report mode, "context restriction" permit OR deny returns the log lines with access which would have rendered a Permit or Deny.
* In report mode, you can use "context restriction" permit to only show access which would have been the permitted. Similarly, use "context restriction" deny for denied access.
* Last, when in enforced mode, use a query string like context restriction rendered for log lines related to denied access.



Monitoring a new rule is recommended for 30 days prior to enforcing it. Learn more about [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor) both in report-only and enabled mode in the CBR documentation.

In order to prepare for the deployment of CBR objects with Terraform in a section further down, go to the browser tab with the [CBR rules](https://cloud.ibm.com/context-based-restrictions/rules). There, delete the previously created rule by clicking on its dot menu and selecting Remove and then confirming with Delete. Thereafter, click on Network zones and delete the previously created zone.





 Step 5: Define the access strategy for your cloud resources 

To set up the right set of rules for context-based restrictions (CBRs), you should have defined the access strategy for your cloud resources. All resources should be protected by identity and access management (IAM). It means, that authentication and authorization checks should be performed before a user or service ID accesses a resource. CBRs add to the protection by cutting off network access based on origin criteria and other rules, but they do not replace proper IAM configuration. Additionally, many services support limiting network traffic to private endpoints, thereby already reducing access options.
From the menu bar, select Manage > Access (IAM).
2. Click the Users page, and then click the name of the user that you want to remove permissions from.
3. Click the Classic infrastructure tab, then click the Permissions, Devices, or VPN subnets tabs.
4. In each tab, deselect specific permissions.
5. To save your changes, click Set and Save. Permissions are downgraded after a few minutes.
* Priority: Within each action type, policies are evaluated in ascending order of priority. Policies to reject traffic are always evaluated first, regardless of their priority. Policies to redirect traffic are evaluated next, followed by policies to forward traffic.
* Redirect: The URL to which the request is redirected, if the action is set to Redirect.
* Status Code: The status code of the response returned by the load balancer, if the action is set to Redirect.
* Forward: The back-end pool of virtual server instances to which the request is forwarded, if the action is set to Forward to pool.



* On the Policies page, you can also create an HTTPS redirect policy with the following configuration:



* Name: Enter a name for the policy, such as my-policy. The name must be unique within the listener.
* Action: Select the Redirect to HTTPS option.
* HTTPS listener: The target HTTPS listener which the traffic from the current HTTP listener will redirect to. Note that you will only see a list of HTTPS listeners whose accept_proxy_proxy value is the same as the HTTP listener.
* Redirect URI (optional): The URL to which the request redirects.
* Status code: The status code of the response returned by the load balancer.



* On the Policies page, click Add rule for your policy. If rules exist for the policy, click the value in the Rules column to add more rules.
* In the Rules window, click Add rule and specify the following information to create a rule. If you create multiple rules for a policy, the policy is applied only when all its rules are matched.



* Condition: Specifies the condition with which a rule is evaluated.
* Type: The type of information to be evaluated by the rule: the name of the host from which the request originated, an HTTP header field, or a path in the URL.
* Value: The value to be matched.
* Key: The name of the HTTP header field to evaluate, if the rule type is Header. For example, to match a cookie in the HTTP header, enter Cookie for the key.











 Creating an application load balancer from the CLI
Multizone clusters only: In the [Subnets for VPC dashboard](https://cloud.ibm.com/vpc-ext/network/subnets), note the IP Range of each subnet that your cluster is attached to.
2. 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 Red Hat OpenShift version 4.5 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
If not, follow the [getting started tutorial](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage) to obtain the prerequisites and become familiar with the console.



 Set a list of authorized IP addresses using a legacy firewall 



1. Start by selecting Storage to view your resource list.
2. Next, select the service instance with your bucket from within the Storage menu. This takes you to the Object Storage Console.
3. Choose the bucket that you want to limit access to authorized IP addresses.
4. Select Access policies from the navigation menu.
5. Select the Authorized IPs tab.
6. Click Add IP addresses, then choose Add.
7. Specify a list of IP addresses in [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing), for example 192.168.0.0/16, fe80:021b::0/64. Addresses can follow either IPv4 or IPv6 standards.
8. Click Add.
9. The firewall will not be enforced until the address is saved in the console. Click Save all to enforce the firewall.
10. Note that all objects in this bucket are only accessible from those IP addresses.







 Remove any IP address restrictions using a legacy firewall 



1. From the Authorized IPs tab, check the boxes next to any IP addresses or ranges to remove from the authorized list.
2. Select Delete, and then confirm the dialog box by clicking Delete again.
3. The updated list won't be enforced until the changes are saved in the console. Click Save all to enforce the new rules.
4. Now all objects in this bucket are only accessible from these IP addresses!



If there are no authorized IP addresses listed this means that normal IAM policies will apply to the bucket, with no restrictions on the user's IP address, unless there are context-based restrictions in place.





 Set a legacy firewall through an API
set security firewall name internal-2-ovpn default-action accept
 
set security firewall name Local default-action 'drop'
set security firewall name Local 'default-log'
set security firewall name Local rule 10 action 'accept'
set security firewall name Local rule 10 description 'RIP' ("/opt/vyatta/etc/cpp.conf" )







 Order of operation for firewalls, NAT, routing and DNS 



 Order of operation issues 

In a scenario where Masquerade Source NAT is deployed on an IBM Cloud® Virtual Router Appliance, you cannot use the firewall to determine access for hosts to the internet. This is because the post NAT address is the same.

For Vyatta 5400 devices, this operation was possible because firewalling was done before NAT, allowing the restriction of hosts to access internet.





 Order of operation workarounds 

A new routing scheme is required for the VRA:

Zoom

![routing dns](https://cloud.ibm.com/docs-content/v1/content/01ccb31b85637ed5f03008c920c9596354caaf98/virtual-router-appliance/images/routing-dns.png)

Routing scheme







 Policy based routing table 



 Policy based routing table issues 

The word "Table" in the configs is optional in v5400 policy-based routing. However, for the VRA, if the action is accept, then the Table field is mandatory. If the action is drop on the VRA config, then the Table field is optional.





 Policy based routing table workarounds 

"Table Main" is an available option in Vyatta 5400 policy-based routing. The equivalent in VRA is "routing-instance default".







 Policy based routing on the tunnel interface 



 Policy based routing on the tunnel interface issues 

On the IBM Cloud® Virtual Router Appliance PBR (Policy-Based Routing), policies can be applied to data plane interfaces for inbound traffic, but not to loopback, tunnel, bridge, OpenVPN, VTI, and IP unnumbered interfaces.
For more information about the v1/rules API, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule).

After you create a rule, it might take up to 10 minutes to before you can update that rule due to IAM TTL response caching.

The following example payload creates a rule that protects the CLUSTER-ID cluster. Only resources in the NETWORK-ZONE-ID zone can access the cluster. Since no operations are specified, resources in the NETWORK-ZONE-ID zone can access both the cluster and management APIs.

{
"description": "Example rule 1",
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "ACCOUNT-ID"
},
{
"name": "serviceName",
"value": "containers-kubernetes"
},
{
"name": "serviceInstance",
"value": "CLUSTER-ID"
}
]
}
],
"contexts": [
{
"attributes":
{
"name": "networkZoneId",
"value": "NETWORK-ZONE-ID"
},
{
"name": "endpointType",
"value": "private"
}
]
}
]
}

The following example payload creates a rule that protects the CLUSTER-ID cluster. Only the resources defined in the NETWORK-ZONE-ID zone can access the cluster. Since the cluster API type is specified, resources in the NETWORK-ZONE-ID zone can access the cluster through the cluster APIs over the private network.

{
"description": "Example rule 2",
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "ACCOUNT-ID"
},
{
"name": "serviceName",
* [Opening required ports in a public allowlist](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_outbound)
* [Opening required ports in a private allowlist](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_private)
* [Opening ports in a public or private allowlist for inbound traffic](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_inbound)



* [Allowing the cluster to access resources through Calico network policies](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_calico_egress)
* [Allowing traffic from your cluster in other services' allowlists or in on-premises allowlists](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_workers)
* [Updating IAM allowlists for Kubernetes Service IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-firewalliam_firewall)



* [Getting your Kubernetes Service subnet IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-firewalliam_cidr_ip)





[Restricting network traffic to edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge)



* [Isolating networking workloads to edge nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge_nodes)
* [Preventing app workloads from running on edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge_workloads)
* [Deploying the Sysdig agent on edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgesysdig-edge)







 Controlling traffic in VPC clusters with ACLs, security groups, and network policies
set security firewall name CPP rule 900 destination address <VRA Public IP Subnet>/24
set security firewall name CPP rule 900 protocol tcp
set security firewall name CPP rule 900 destination port 22
commit
3. Validate VRA SSH administrative access over the IBM internal network. If access is lost to the VRA via SSH after performing commits, you can access the VRA via the KVM Console available at the Device Details page of the VRA via the Action menu.



This completes the setup of the secure private network enclosure protecting a single firewall zone containing a VLAN and subnet. Additional firewall zones, rules, virtual and bare-metal servers, VLANs and subnets can be added following the same instructions.





 Step 7: Remove resources 

In this step, you will clean up the resources to remove what you created.



* Cancel any virtual servers or bare-metal servers
* Disassociate and [Cancel any VLANs](https://cloud.ibm.com/docs/vlans?topic=vlans-cancel-vlan)
* Cancel the VRA



The VRA is on a monthly paid plan. Cancellation does not result in a refund. It is suggested to only cancel if this VRA will not be required again in the next month. If a dual VRA High-Availability cluster is required, this single VRA can be upgraded on the [Gateway Details](https://cloud.ibm.com/classic/network/gatewayappliances/) page.





 Related content 



* [IBM Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-accessing-and-configuring-the-ibm-virtual-router-appliance)
* [Static and Portable IP Subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-about-subnets-and-ipsabout-subnets-and-ips)
- name: Veeam firewall rule UDP 111 in
community.windows.win_firewall_rule:
name: Veeam port mapper service (UDP-in)
group: Veeam
localport: 111
action: allow
direction: in
protocol: udp
state: present
enabled: yes

- name: Veeam firewall rule TCP 1058 in
community.windows.win_firewall_rule:
name: Veeam Mount acceptor port of vPower NFS service (TCP-in)
group: Veeam
localport: 1058
action: allow
direction: in
protocol: tcp
state: present
enabled: yes

- name: Veeam firewall rule TCP 2049 in
community.windows.win_firewall_rule:
name: Veeam NFS acceptor port of vPower NFS service (TCP-in)
group: Veeam
localport: 2049
action: allow
direction: in
protocol: tcp
state: present
enabled: yes

- name: Veeam firewall rule TCP 2500-3300 in
community.windows.win_firewall_rule:
name: Veeam data transmission channels (TCP-in)
group: Veeam
localport: 2500-3300
action: allow
direction: in
protocol: tcp
state: present
enabled: yes
Show more

In the code snippet, Veeam port mapper service, mount acceptor port and NFS acceptor port are used by vPower NFS service that presents the backup files to VMware ESXi™ hosts. Veeam data transmission channels are used between Veeam components that include the Veeam Hardened backup repository.





 Adding the Linux hardened backup repository 

The following code snippet adds the Linux hardened repository as a Veeam managed server, and then adds the managed server as a backup repository.

- name: Connect to the local VBR server
win_shell: Connect-VBRServer
lhbr_user: veeamlhbr
lhbr_password: "{{ vault_lhbr_password }}"
lhbr_vbr_name: <lhbr_vbr_name>
lhbr_fqdn: <lhbr_fqdn>
immutability_period: <immutability_period>
max_concurrent_jobs: <max_concurrent_jobs>

Replace <lhbr_vbr_name>, <lhbr_fqdn>, and <immutability_period> in the previous code snippet with the values that you captured in the earlier steps. The previous code does the following actions:



* Defines that the playbook is run on the hosts that are defined as vbr in the inventory file.
* Defines a file that contains other variables, called vault. The vault file that was created in the previous step, is encrypted, and contains sensitive variables, such as passwords.
* Defines the shortname that is used in designating the Linux hardened repository <lhbr_vbr_name>, and the FQDN of the server.







 Creating Windows firewall rules 

The following code snippet adds Windows® firewall rules to allow inbound traffic to the Veeam backup server.

tasks:
- name: Veeam firewall rule TCP 111 in
community.windows.win_firewall_rule:
name: Veeam port mapper service (TCP-in)
group: Veeam
localport: 111
action: allow
direction: in
protocol: tcp
state: present
enabled: yes

- name: Veeam firewall rule UDP 111 in
community.windows.win_firewall_rule:
name: Veeam port mapper service (UDP-in)
group: Veeam
localport: 111
action: allow
direction: in
protocol: udp
state: present
enabled: yes

- name: Veeam firewall rule TCP 1058 in
community.windows.win_firewall_rule:
* [Calico network policies](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_calico_egress): If you use Calico network policies to act as an allowlist to restrict all worker node egress, you must allow your worker nodes to access the resources that are required for the cluster to function.
* [Other services or network allowlists](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_workers): To allow your cluster to access services that run inside or outside IBM Cloud or in on-premises networks and that are protected by an allowlist, you must add the IP addresses of your worker nodes in that allowlist.





 Opening ports in a corporate allowlist 

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, you must allow access to run [ibmcloud, ibmcloud ks, and ibmcloud cr commands](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_bx), [kubectl commands](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_kubectl), and [calicoctl commands](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_calicoctl) from your local system.



 Running ibmcloud, ibmcloud ks, and ibmcloud cr commands from behind an allowlist 

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run ibmcloud, ibmcloud ks and ibmcloud cr commands, you must allow TCP access for IBM Cloud, IBM Cloud Kubernetes Service, and IBM Cloud Container Registry.



1. Allow access to cloud.ibm.com on port 443 in your allowlist.
2. Verify your connection by logging in to IBM Cloud through this API endpoint.

ibmcloud login -a https://cloud.ibm.com/
3. Allow access to containers.cloud.ibm.com on port 443 in your allowlist.
4.
curl --connect-timeout 10 <loadbalancer_IP>:80
7. If you have access to another system that has a different IP address, try to access the NLB from that system.

curl --connect-timeout 10 <loadbalancer_IP>:80

The connection times out because that system's IP address isn't allowed.



At this point, all traffic to the public node ports and NLB is blocked. Only traffic from your allowed system IP is allowed.





 Step 4: Deny incoming traffic from specific IPs to the NLB 

In the previous lesson, you blocked all traffic and allowed only a few IPs. That scenario works well for testing purposes when you want to limit access to only a few controlled source IP addresses. However, the PR firm has apps that need to be widely available to the public. You need to make sure that all traffic is permitted except for the unusual traffic you are seeing from a few IP addresses. A denylist is useful in a scenario like this one because it can help you prevent an attack from a small set of IP addresses.

In this lesson, block traffic from your own system's source IP address. At the end of Lesson 4, all traffic to the public node ports is blocked, and all traffic to the public NLB is allowed. Only traffic from your specific system IP to the NLB is blocked.

Zoom

![The web server app is exposed by public NLB to the internet. Only traffic from your system IP is blocked.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_tutorial_policies_L4.png)

Figure 4. The webserver app is exposed by public NLB to the internet.



1. Clean up the allowlist policies you created in the previous lesson.



* Linux:

calicoctl delete GlobalNetworkPolicy deny-lb-port-80

calicoctl delete GlobalNetworkPolicy allowlist