vania-janet/multiturn-rag-retrieval-data huggingface dataset:
set zone-policy zone MGMT from OUTSIDE firewall name OUTSIDE2INSIDE
set zone-policy zone MGMT from SLSERVICE firewall name SLSERVICE2INSIDE
set zone-policy zone SLSERVICE from MGMT firewall name INSIDE2SLSERVICE
set zone-policy zone SLSERVICE from VMACCESS firewall name INSIDE2SLSERVICE
set zone-policy zone SLSERVICE from STORAGE firewall name INSIDE2SLSERVICE
set zone-policy zone STORAGE from SLSERVICE firewall name SLSERVICE2INSIDE
set zone-policy zone STORAGE from MGMT firewall name MGMT2STORAGE
commit
save







 Syncing with other Brocade vRouter (Vyatta) in the HA Pair 

Since you set up one of the Brocade vRouter’s (Vyatta) in the HA pair, you must sync the changes to the other gateway device.

Use the following commands in configure mode:

set system config-sync remote-router <OTHER BROCADE VROUTER (VYATTA) IP> password <OTHER BROCADE VROUTER (VYATTA) PASSWORD>
set system config-sync remote-router <OTHER BROCADE VROUTER (VYATTA) IP> sync-map 'SYNC'
set system config-sync remote-router <OTHER BROCADE VROUTER (VYATTA) IP> username <OTHER BROCADE VROUTER (VYATTA) USERNAME>
set system config-sync sync-map SYNC rule 1 action 'include'
set system config-sync sync-map SYNC rule 1 location 'nat'
set system config-sync sync-map SYNC rule 2 action 'include'
set system config-sync sync-map SYNC rule 2 location 'firewall'
set system config-sync sync-map SYNC rule 3 action 'include'
set system config-sync sync-map SYNC rule 3 location 'vpn'
set system config-sync sync-map SYNC rule 4 action 'include'
set system config-sync sync-map SYNC rule 4 location 'interfaces tunnel'
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 

Firewalls are managed with the [COS Resource Configuration API](https://cloud.ibm.com/apidocs/cos/cos-configuration). This new REST API is used for configuring buckets.

Users with the manager role can view and edit the list of allowed IP addresses from any network in order to prevent accidental lockouts.
Repeat steps 2 - 11 for each subnet that you found in step 1.



ACL rules are applied to traffic in a specific order. If you want to add a rule after you complete these steps, ensure that you add the rule before the deny-all-inbound or deny-all-outbound rule. If you add a rule after these rules, your rule is ignored, because the packet matches the deny-all-inbound and deny-all-outbound rules and is blocked and removed before it can reach your rule. Create your rule in the proper order by including the --before-rule-name deny-all-(inbound|outbound) option.
Security scenario: Customers want granular control over traffic at an instance level (apart from network-level firewalls). However, at the same time, the costs of a shared hardware firewall can add up quickly if you need to protect multiple servers in different data centers.

Solution: You do not incur extra charges for using security groups. You can use security groups for all virtual servers that need protection in any of our global data centers.





 Globally scalable and easily manageable firewall 

Security scenario: You want to avoid configuring firewall rules on each server separately. Instead, you want an easily manageable firewall solution that spans servers in different global data centers.

Solution: Define N security groups for N different types of servers in your cloud workload. Manage all rules for a security group in one place. Manage the security group associations with the virtual servers.
end_address = "192.168.100.254"
}

dns1 = "9.9.9.9"
dns2 = "1.1.1.1"
}
Show more





 Create a firewall and SNAT rule to access the Internet 

You can create rules to allow or deny traffic, this section creates a firewall and SNAT rule to allow traffic from the VDC network to reach the Internet with no additional restrictions.

Zoom

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

Access to Internet

resource "vcd_nsxv_firewall_rule" "rule_internet" {
edge_gateway = module.ibm_vmware_solutions_shared_instance.edge_gateway_name
name = "${vcd_network_routed.tutorial_network.name}-Internet"

action = "accept"

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

destination {
ip_addresses = []
}

service {
protocol = "any"
}
}

resource "vcd_nsxv_snat" "rule_internet" {
edge_gateway = module.ibm_vmware_solutions_shared_instance.edge_gateway_name
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
Rules with a 'tcp' or 'udp' protocol may have an unset port range (to apply the rule to all traffic), or they may specify a port range. To restrict traffic to a single port, set both the minimum and maximum port to the port value. For example, the following command would create a rule to allow SSH on port 22: ibmcloud is security-group-rule-add <id> inbound tcp --port-min 22 --port-max 22.

For further information on security group rule configurations, refer to the [API documentation](https://cloud.ibm.com/apidocs/vpc-on-classic).





 security_group_port_range_invalid_protocol 

Message: A port range was specified with a protocol of 'icmp'. A port range is only valid for a protocol of 'tcp' or 'udp'.

Rules with an 'icmp' protocol have a type and code. Rules with 'tcp' or 'udp' protocols have a port range. For further information on security group rule configurations, refer to the [API documentation](https://cloud.ibm.com/apidocs/vpc-on-classic).





 security_group_remote_group_not_in_vpc 

Message: The remote group is not in the same VPC as this security group.

Security group rules may refer to a remote security group, allowing traffic between attached interfaces of the two groups. Remote security groups must be in the same VPC. Use GET /v1/security_groups?2019-01-01 or ibmcloud is security-groups to view current security groups and their VPCs.

For further instructions to fix this problem, refer to the [Using Security Groups document](https://cloud.ibm.com/docs/vpc-on-classic-network?topic=vpc-on-classic-network-using-security-groups).





 security_group_remoting_rules 

Message: Cannot delete the security group while remoting rules are attached.

The security group contains one or more rules referencing a remote security group.
Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 80 Allow HTTP traffic to the internet 
 Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 443 Allow HTTPS traffic to the internet 
 Outbound Allow 0.0.0.0/0 10.10.10.0/24 All All Allow all outbound traffic to the subnet 10.10.10.0/24 where the web servers are placed 
 Outbound Deny 0.0.0.0/0 0.0.0.0/0 All All Deny all other traffic outbound 



This example illustrates general cases only. In your scenarios, you might want to have more granular control over the traffic:



* You might have a network administrator who needs access to the 10.10.10.0/24 subnet from a remote network for operation purposes. In that case, you need to allow SSH traffic from the internet to this subnet.
* You might want to narrow down the protocol scope that you allow between your two subnets.









 Example steps 

The following example steps skip the prerequisite steps of using the CLI to create a VPC, which must be done first. For more information, see [Using the CLI to create VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-cli).



 Step 1. Create the ACLs 

Use the following CLI commands to create two ACLs, named my_web_subnet_acl and my_backend_subnet_acl:

ibmcloud is network-acl-create my-web-subnet-acl $vpc_id --source-acl-id $old_acl_id
ibmcloud is network-acl-create my-backend-subnet-acl $vpc_id --source-acl-id $old_acl_id

The response includes the newly created ACL IDs. Save the IDs of both ACLs to be used in later commands.
set firewall name allow rule 10 ipsec

However, with IBM Cloud® Virtual Router Appliance, there is no IPsec.





 IPSEC "match-none" workarounds 

Possible alternative rules for VRA devices:

match-ipsec Inbound IPsec packets
match-none Inbound non-IPsec packets







 IPSEC 'match-ipsec" 



 IPSEC 'match-ipsec" issues 

With Vyatta 5400 devices, the following firewall rules are allowed:

set firewall name OUTSIDE_LOCAL rule 50 action 'accept'
set firewall name OUTSIDE_LOCAL rule 50 ipsec 'match-ipsec'

However, with IBM Cloud® Virtual Router Appliance, there is no IPsec.





 IPSEC 'match-ipsec" workarounds 

Add the protocols ESP and AH (IP protocols 50 and 51 respectively).

The action rule can be either accept or drop, as shown in the following example:

set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> destination port 4500
set security firewall name <name> rule <rule-no> protocol udp
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol ah
set security firewall name <name> rule <rule-no> action accept
set security firewall name <name> rule <rule-no> protocol esp







 Site-to-site IPsec with DNAT 



 Site-to-site IPsec with DNAT issues 

IPsec (prefix-based) does not work with DNAT.

server (10.71.68.245) -- vyatta 1 (11.0.0.1)
From the Classic Infrastructure menu, select Security > Network Security > Security Groups to get to the Security Groups page.
3. On the Security Groups page, click a security group name to open the Details page and click the Create rule + button.
4. On the Create Rule page, enter all appropriate attributes (such as direction, IP type, protocol, and source/destination information). When finished, click OK.



Selecting the optional source or destination fields restrict the new rule so it only applies to traffic to/from the specified source/destination. Source and destination fields can specify either a Classless Inter-Domain Routing (CIDR) block or a security group.

A CIDR block facilitates routing of a block of IP addresses. If you select CIDR Block as the type, then you must specify an IP address range.

If you select Security Groups as the type, then you must select from a list of existing security groups. This selection allows any IP address from a device that is attached to the selected security group. If a virtual server is configured to have multiple IP addresses, only the primary IPv4 and IPv6 addresses are used by these remote security group rules.
Bind particular zones to interfaces on the Brocade vRouter (Vyatta).

Use the following commands in configure mode:

set zone-policy zone OUTSIDE description “Internet Zone”
set zone-policy zone OUTSIDE default-action drop
set zone-policy zone OUTSIDE interface bond1
set zone-policy zone SLSERVICE description “SoftLayer Services”
set zone-policy zone SLSERVICE default-action drop
set zone-policy zone SLSERVICE interface bond0
set zone-policy zone MGMT description “Management VMs & ESX Host Access”
set zone-policy zone MGMT default-action drop
set zone-policy zone MGMT interface bond0.1101
set zone-policy zone STORAGE description “Storage”
set zone-policy zone STORAGE default-action drop
set zone-policy zone STORAGE interface bond0.1102
set zone-policy zone VMACCESS description “VM Access”
set zone-policy zone VMACCESS default-action drop
set zone-policy zone VMACCESS interface bond0.1103
commit
save
Show more





 Applying firewall rules to zones 

Apply the firewall rules to the communication between zones.

Use the following commands in configure mode:

set zone-policy zone OUTSIDE from MGMT firewall name INSIDE2OUTSIDE
set zone-policy zone OUTSIDE from VMACCESS firewall name INSIDE2OUTSIDE
set zone-policy zone VMACCESS from OUTSIDE firewall name OUTSIDE2INSIDE
set zone-policy zone VMACCESS from SLSERVICE firewall name SLSERVICE2INSIDE
set zone-policy zone MGMT from OUTSIDE firewall name OUTSIDE2INSIDE
set zone-policy zone MGMT from SLSERVICE firewall name SLSERVICE2INSIDE
set zone-policy zone SLSERVICE from MGMT firewall name INSIDE2SLSERVICE
set zone-policy zone SLSERVICE from VMACCESS firewall name INSIDE2SLSERVICE
set zone-policy zone SLSERVICE from STORAGE firewall name INSIDE2SLSERVICE
This example creates three Static Groups, one for each routed virtual data center network and one which includes all routed virtual data center networks.

 Note. You need to create Static Groups to be used in firewall rules.
 You can use vdc_networks as keys here.

security_groups = {
sg-application-network-1 = {
description = "Static Group for application-network-1"
address_targets = ["application-network-1"]
},
sg-db-network-1 = {
description = "Static Group for db-network-1"
address_targets = ["db-network-1"]
},
sg-all-routed-networks = {
description = "Static Group for all VDC networks"
address_targets = ["application-network-1", "db-network-1"]
},
}
Show more
9. Define firewall rules.

The variable firewall_rules defines the firewall rules to be created. See the provided examples and modify based on your needs.

 Note. Use "ALLOW or "DROP".

 Note. Use Director UI to get the name for the Application
 profiles."

firewall_rules = {
app-1-egress = {
action = "ALLOW"
direction = "OUT"
ip_protocol = "IPV4"
destinations = [] These refer to IP sets (ip_sets or nat_rules) or Static Groups (vdc_networks)
sources = ["sg-application-network-1", "sg-db-network-1"] These refer to IP sets (ip_sets or nat_rules) or Static Groups (vdc_networks)
system_app_ports = []
logging = false
enabled = true
},
dnat-to-app-1-ingress = {
action = "ALLOW"
direction = "IN"
ip_protocol = "IPV4"
You can use security groups to limit network traffic on your virtual servers. Use security groups to enact a set of IP filter rules that define how to handle incoming and outgoing traffic to both the public and private interfaces of a virtual server instance. For more information, see [Getting started with security groups](https://cloud.ibm.com/docs/security-groups?topic=security-groups-getting-started).





 Configure firewalls 

Hardware firewalls are also available for even more protection. Hardware firewalls are provisioned on demand with no downtime. If rules are established properly, a firewall can protect your server from unwanted activity. After you order a firewall, it must be enabled and rules must be set.

For more information, see the following information.



* [Hardware Firewalls (Shared)](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-about-hardware-firewall-shared-)
* [Hardware Firewalls (Dedicated)](https://cloud.ibm.com/docs/hardware-firewall-dedicated?topic=hardware-firewall-dedicated-about-the-hardware-firewall-dedicated-)







 Schedule backups 

Backups ensure that your data is safely stored outside of your device and protected if it is lost. The following backup services are available to store your data in a secure location in case you ever need to reload your information onto your device:



* IBM Cloud Backup for Classic is an automated, agent-based backup system. This is a popular “set-and-forget” solution for managing your device. It is compatible with Microsoft software including Exchange and SQL through extra plug-ins. IBM Cloud Backup for Classic users interact with this service through IBM Cloud Backup for Classic’s WebCC web-based application. For more information, see [Getting started with IBM Cloud Backup for Classic services](https://cloud.ibm.com/docs/Backup?topic=Backup-getting-started).
* R1Soft Continuous Data Protection is backup software that can be installed on your server or self-managed virtual machine.
set security firewall name [firewall name] rule [rule number] disable
commit
2. Unhook the entire named rule set from the necessary interface by running:

delete interfaces dataplane [interface] firewall [type] [firewall name]
commit



Incorrect use of these commands can wipe out your interface configuration.





 Why would I want to run two Vyatta devices in a High Availability (HA) pair? 

Most cloud customers want HA services. This is so that your workload is hosted on at least two separate (hardware) machines, or even better, in two separate availability zones (think data centers), so that if one fails, the other is able to continue the service. If one machine fails, there is a failover to the other machine, which means that the service can keep running. This is what is referred to as an HA service — it’s almost always available.





 How can I enable root logins to the VRA? 

To enable root access through SSH, run the following command:

set service ssh allow-root

Allowing root access that uses SSH is considered unsafe.

An alternative to accessing a root shell is to either log in as another user and elevate to root locally with su -, or allow sudo commands to superusers. For example, to configure the Vyatta as a superuser:

set system login vyatta level superuser
If available, monitoring is recommended for 30 days before you enforce a rule.

Report-only mode is not available for all services, so review each service's documentation to learn about how they integrate with context-based restrictions.

You can monitor the impact of your enabled and report-only rules. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).





 Defining the scope of a rule 

Define the APIs that you want to protect to narrow the scope of a rule's restrictions. This way, you can specify granular protections for different APIs that have distinct access requirements.

For example, you might create a rule that targets a data plane API so that it is only accessible from a Kubernetes cluster, or wherever your compute infrastructure exists. Then, you can create a rule that targets your control plane API that interacts with the cloud console so that it is only accessible from behind your organization's VPN.

Only some services support the ability to scope a rule by API.

With some services, you can restrict the actions of all APIs on your resources by default, which includes all current and future APIs that the service might support. Or, select specific APIs. For example, [Kubernetes](https://cloud.ibm.com/docs/containers?topic=containers-cbr&interface=uicbr-overview) has custom service APIs that you can restrict access to based on the context of the request. Review each service's documentation to learn more about how they integrate with context-based restrictions.

You can also skip APIs to restrict all operations on the service that you select.







 Contexts 

Contexts define where your resource can be accessed. A context is made up of the allowed endpoint types and network zones that you configure.



* If a context includes network zones, then access is granted only when the request is created from within one of those zones.
* If a context includes service endpoint types, then access is granted only when the request is received over a connection that matches one of those types.
Inbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 443 Allow HTTPS traffic from the internet 
 Inbound Allow 10.10.20.0/24 0.0.0.0/0 All All Allow all inbound traffic from the subnet 10.10.20.0/24 where the back-end servers are placed 
 Inbound Deny 0.0.0.0/0 0.0.0.0/0 All All Deny all other traffic inbound 
 Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 80 Allow HTTP traffic to the internet 
 Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 443 Allow HTTPS traffic to the internet 
 Outbound Allow 0.0.0.0/0 10.10.20.0/24 All All Allow all outbound traffic to the subnet 10.10.20.0/24 where the back-end servers are placed 
 Outbound Deny 0.0.0.0/0 0.0.0.0/0 All All Deny all other traffic outbound 







 ACL-2 example rules 



Table 2. Example rules for ACL-2

 Inbound/Outbound Allow/Deny Source IP Destination IP Protocol Port Description 

 Inbound Allow 10.10.10.0/24 0.0.0.0/0 All All Allow all inbound traffic from the subnet 10.10.10.0/24 where the web servers are placed 
 Inbound Deny 0.0.0.0/0 0.0.0.0/0 All All Deny all other traffic inbound 
 Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 80 Allow HTTP traffic to the internet 
 Outbound Allow 0.0.0.0/0 0.0.0.0/0 TCP 443 Allow HTTPS traffic to the internet 
 Outbound Allow 0.0.0.0/0 10.10.10.0/24 All All Allow all outbound traffic to the subnet 10.10.10.0/24 where the web servers are placed
You can allow access for all clients, or you can allow only certain source IPs or subnets to access these applications. TCP 80 or 443 All sources, or specific source IP addresses or subnets 
 If you use your own security group for any LBaaS instances that you use to expose other applications, then within that security group you must allow any intended sources to access the appropriate ports and protocols. TCP, UDP, or both LBaaS ports Any sources, or specific source IPs or subnets 







 Outbound rules 



Required outbound rules for VPE and VPC ALB security groups

 Rule purpose Protocol Port or Value Destination 

 Allow the ALB to send traffic to the cluster workers on the TCP NodePort range TCP 30000 - 32767 Any 
 Allow the ALB to send traffic to the cluster workers on the UDP NodePort range UDP 30000 - 32767 Any 
 If you use your own security group for the LBaaS for Ingress, you must allow TCP traffic from cluster worker nodes to port 443. If you do not already allow all TCP traffic port to 443, such as if you filter traffic by source IP, then allowing traffic from cluster worker nodes is the minimum requirement for the Ingress health checks to succeed. TCP 443 Security group kube-<cluster_ID> 











 Creating security group rules 

You can add inbound and outbound rules to the default VPC security groups. If you modify the randomly named VPC security group and the cluster-level kube-<cluster-id> security group or replace the kube-<vpc-id> security group, you must make sure that the [minimum inbound and outbound rules](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uivpc-sg-inbound-outbound) are still met. Do not modify the kube-<vpc-id> security group itself.



 Creating rules in the console 



1. From the [Virtual private cloud dashboard](https://cloud.ibm.com/vpc-ext/network/vpcs), click the name of the Default Security Group for the VPC that your cluster is in.
2.