vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can configure your VRA server directly by using SSH (Secure Shell) with the passwords that are provided in the Hardware Details section of the IBM Cloud console.





 Is my password safe? 

Yes. All VRAs are assigned random passwords visible only to the account holder. Passwords are easily changed, as are SSH public keys and admin IP access restrictions.





 Can I get VRA without a gateway appliance? 

Yes, but it can only manage traffic between the VRA's public and private interfaces. VLANs and HA require the gateway appliance fixture.





 Is all network traffic sent through the VRA? 

No. The gateway appliance allows you to select the private and public network segments (VLANs) that you want to route through the VRA. You can change and bypass VLAN selections at any time. VRA also allows you to define IP-based rules that apply to subnets or IP ranges. Such rules function only if the VLANs containing those subnets are routed through the VRA.





 Can a VRA or dedicated firewall prevent new server provisions? 

Yes. Whenever possible, you shouldn't lock down your network until you've populated it with the servers you plan to use.

IBM support is forbidden by policy to examine or alter VRA or dedicated firewall configuration without a customer's explicit involvement, so in most cases support cannot know that a VRA is responsible for stalled or failed server provisions.

It is the customer's responsibility to ensure that the VRA or firewall is configured to permit automated server provisions before the server order is placed. Provisions that are blocked by a customer-managed VRA or firewall are the customer's responsibility to resolve. Such provisioning delays are not subject to SLAs or credits. Ordered systems can be returned to inventory (after customer data is expunged) if the customer does not respond quickly.

Likewise, if a VRA or firewall is bypassed after an order is placed, it's still likely that the order will fail. There might be a narrow window during which automation retries are attempted. It is best that the entire provision process proceed without network interference.





 What firewall products does IBM offer?
If no return traffic is seen, the data center networking team will need to monitor the traffic flows at the VPN and tunnel interfaces at the remote site to localise the issue.





 Step 5: Create static IP route 

Create the VRA routing to direct traffic to the remote subnet via the tunnel.



1. Create static route in VRA edit mode.

set protocols static route <DC Subnet/CIDR> next-hop <Remote tunnel IP>
2. Review the VRA routing table from the VRA command line. At this time no traffic will transverse the route as no firewall rules exist to allow traffic via the tunnel. Firewall rules are required for traffic initiated at either side.

show ip route







 Step 6: Configure firewall 



1. Create resource groups for allowed icmp traffic and tcp ports.

set res group icmp-group icmpgrp type 8
set res group icmp-group icmpgrp type 11
set res group icmp-group icmpgrp type 3

set res group port tcpports port 22
set res group port tcpports port 80
set res group port tcpports port 443
commit
2. Create firewall rules for traffic to the remote subnet in VRA edit mode.

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

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

set security firewall name APP-TO-TUNNEL rule 200 protocol icmp
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
See [Schematics firewall, allowed IPs](https://cloud.ibm.com/docs/schematics?topic=schematics-allowed-ipaddresses) for details of the IP addresses Schematics uses and must be allowed access. When using a bastion host, SSH forwarding is used to connect to the target VSIs. To validate access the command ssh -J bastion-ip vsi-ip.

Example as-is IBM Cloud® VPC configurations with bastion hosts are available in the [Cloud-Schematics repo](https://github.com/orgs/Cloud-Schematics/repositories?q=bastion&type=all&language=&sort=). Follow the tutorial [Discover best-practice VPC configuration for application deployment](https://developer.ibm.com/articles/secure-vpc-access-with-a-bastion-host-and-terraform/) for guidance on creating a suitable network configuration.
* Why does my action job display a DEPRECATION WARNING message?

In the action settings page you, need to set the input variable as ansible_python_interpreter = auto as shown in the screen capture to avoid DEPRECATION WARNING message.

![Configuring input variable to silence warning message](https://cloud.ibm.com/images/advanced_inputvariable.png)

Configuring input variable to silence warning message
* How can I resolve that might not run action error while provisioning WinRM by using Schematics action?
[Architecture](https://cloud.ibm.com/docs-content/v1/content/01ccb31b85637ed5f03008c920c9596354caaf98/virtual-router-appliance/includes/solution-tutorials/includes/solution-tutorials/images/solution35-nat-config-private/vra-nat.png)

Figure 1. Architecture diagram of the tutorial



1. Document required Internet services.
2. Setup NAT.
3. Create Internet firewall zone and rules.







 Before you begin 

This tutorial enables hosts in the secure private network enclosure created by the [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure) tutorial to access public Internet services. That tutorial must be completed first.





 Step 1: Document Internet services 

The first step is to identify the services that will be accessed on the public Internet and to document the ports that must be enabled for outbound and corresponding inbound traffic from the Internet. This list of ports will be required for the firewall rules in a later step.

In this example only http and https ports are enabled as these cover a majority of requirements. DNS and NTP services are provided from the IBM Cloud private network. If these and other services such as SMTP (Port 25) or MySQL (Port 3306) are required, additional firewall rules will be necessary. The two basic port rules are:



* Port 80 (http)
* Port 443 (https)



Verify if the third party service supports defining a list of allowed source addresses. If yes, the public IP address of the VRA will be required to configure the third party service to limit access to the service.





 Step 2: NAT masquerade to Internet 

Follow the instructions here to configure external Internet access for hosts in the APP zone using NAT masquerade.



1. SSH into VRA and enter [edit] (config) mode.
[Architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution35-nat-config-private/vra-nat.png)

Figure 1. Architecture diagram of the tutorial



1. Document required Internet services.
2. Setup NAT.
3. Create Internet firewall zone and rules.







 Before you begin 

This tutorial enables hosts in the secure private network enclosure created by the [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure) tutorial to access public Internet services. That tutorial must be completed first.





 Step 1: Document Internet services 

The first step is to identify the services that will be accessed on the public Internet and to document the ports that must be enabled for outbound and corresponding inbound traffic from the Internet. This list of ports will be required for the firewall rules in a later step.

In this example only http and https ports are enabled as these cover a majority of requirements. DNS and NTP services are provided from the IBM Cloud private network. If these and other services such as SMTP (Port 25) or MySQL (Port 3306) are required, additional firewall rules will be necessary. The two basic port rules are:



* Port 80 (http)
* Port 443 (https)



Verify if the third party service supports defining a list of allowed source addresses. If yes, the public IP address of the VRA will be required to configure the third party service to limit access to the service.





 Step 2: NAT masquerade to Internet 

Follow the instructions here to configure external Internet access for hosts in the APP zone using NAT masquerade.



1. SSH into VRA and enter [edit] (config) mode.

SSH vyatta@<VRA Private IP Address>
configure
Securing the host operating system 

The IBM Cloud® Juniper vSRX runs as a Virtual Machine on a bare-metal server installed with Ubuntu and KVM. To secure the host OS, you should ensure that no other critical services are hosted on the same OS.



 SSH access 

The IBM Cloud® Juniper vSRX can be deployed with public and private network access or private network access only. By default, password based SSH access to the public IP of the host OS will be disabled on new provisions and OS reloads. Access to the host can be achieved through the private IP address. Alternatively, key based authentication can be used to access the public IP. To do so, specify the public SSH key when placing a new Gateway order .

Some existing deployments of the IBM Cloud® Juniper vSRX might allow password based SSH access to the public IP of the host OS. For these deployments, you can manually disable password based SSH access to the public IP of the OS by following these steps:



1. Modify /etc/ssh/sshd_config



* Ensure the following values are set.

ChallengeResponseAuthentication no
PasswordAuthentication no
* Add the following filter rules to the end of the file.

Match Address 10.0.0.0/8
Password Authentication yes



2. Restart the SSH service using the command /usr/sbin/service ssh restart.



The procedure above ensures addresses in the private infrastructure network 10.0.0.0/8 subnet are allowed SSH access. This access is needed for actions such as:



* OS reloads
* Cluster rebuilding
* Version upgrades







 Firewalls 

Implementing an Ubuntu firewall (UFW, Iptables, and so on) without required rules can cause the vSRX HA cluster to be disabled. The vSRX solution depends on heartbeat communication between the primary and secondary nodes. If the firewall rules do not allow communication between the nodes, then cluster communication will be lost.

The vSRX architecture influences the firewall rules discussed below.
To set up public connectivity for cluster that is connected to a private VLAN only, you can configure a firewall, such as a [Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vra), in front of your worker nodes and enable network traffic to these URLs and IP addresses. 
 Limit public internet connectivity with edge nodes If you don't create a cluster with a gateway enabled, every worker node is configured to accept app pods and associated load balancer or ingress pods. You can label worker nodes as [edge nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge) to force load balancer and Ingress pods to be deployed to these worker nodes only. In addition, you can [taint your worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge_workloads) so that app pods can't schedule onto the edge nodes. With edge nodes, you can isolate the networking workload on fewer worker nodes in your cluster and keep other worker nodes in the cluster private. 







 What if I want to connect my cluster to an on-prem data center? 

To connect your worker nodes and apps to an on-prem data center, you can configure a [VPN IPSec endpoint with a strongSwan service, a Virtual Router Appliance, or with a Fortigate Security Appliance](https://cloud.ibm.com/docs/containers?topic=containers-vpnvpn).





 Network segmentation and privacy for VPC clusters 

To protect your network and limit the range of damage that a user can do when access to a network is granted, you must make sure that your workloads are as isolated as possible and that you limit the number of apps and worker nodes that are publicly exposed.





 What network traffic is allowed for my VPC cluster by default?
For more information, see [Creating security groups and rules](https://cloud.ibm.com/docs/security-groups?topic=security-groups-creating-security-groups)







 Why is my migration not working? 

If your migration is stuck or didn't complete properly, create a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-get-supportfaqopen-support-case) for assistance.





 Resource considerations for virtual server instances 



 What's happening 

When you provision a virtual server, you might receive the following error message:

Insufficient capacity to complete the request.

When provisioning fails, all the virtual server instances within that particular request fail.





 Why it's happening 

An error occurs when the router or data center has insufficient available resources to fulfill the service request. Resource availability changes frequently, so you might wait and try again later.





 How to fix it 

You can attempt to provision again by using the following strategies:



* Provision specifying a different router.
* Provision without specifying a router.
* Provision in a different data center.

You can provision GPUs only in the following data centers: dal10, dal12, dal13, lon04, lon06, wdc07, tok02, syd04, and fra02
* Provision fewer instances.
* Spread out instances by provisioning to multiple data centers.
* Provision smaller instance sizes.
* Alter the instance storage from SAN to LOCAL or LOCAL to SAN.









 Why can't I view the password for a recently provisioned virtual server even though you have the correct permissions? 



 Why it's happening 

This problem can occur if a firewall prevents the provisioning framework from updating the password value.





 How to fix it 



* Option 1: Update the firewall to allow the IBM Cloud service IP ranges as described in the firewall [documentation](https://cloud.ibm.com/docs/vsrx?topic=hardware-firewall-shared-ibm-cloud-ip-ranges). These ranges allow for provisioning, monitoring, and management.
Note: The IPs or ports provided must be the external IP address that the Secure Gateway servers will see, not the local IP address of the machine making the request.



 Adding iptables rules 

When adding rules to iptables, you can provide individual IPs or an IP range along with either a single port or a port range. All ranges provided are inclusive. The following table has some examples as well as how they will resolve within iptables:



 IP Addresses Ports Results 

 1.2.3.4 5000 Only IP 1.2.3.4 from port 5000 will be allowed. 
 1.2.3.4-2.3.4.5 5000 All IPs between 1.2.3.4 and 2.3.4.5 from port 5000 will be allowed. 
 1.2.3.4 5000:10000 Only IP 1.2.3.4 from ports 5000 to 10000 will be allowed. 
 1.2.3.4-2.3.4.5 5000:10000 All IPs between 1.2.3.4 and 2.3.4.5 from ports 5000 to 10000 will be allowed. 
 1.2.3.4 Only IP 1.2.3.4 from any port will be allowed. 
 5000 Any IP from port 5000 will be allowed. 



Specific rules can also be associated with an application. For more information on creating associated rules, see [how to create iptables rules for your app](https://cloud.ibm.com/docs/services/SecureGateway?topic=SecureGateway-iptables-rules).







 Configuring Proxy Options 

If your on-premises destination is located behind a SOCKS proxy, you can configure the proxy settings for your destination in the Proxy Options panel. ![Proxy Options Panel](https://cloud.ibm.com/docs-content/v1/content/690bf9a59650e0582967be8899e39840589532f7/SecureGateway/images/proxyOptions.png?raw=true)
Configuring the Hardware Firewall 

Configuring your Hardware Firewall is as simple as creating a set of rules to allow access to certain IP addresses/ports from specific internet addresses while denying traffic from other sources.



 Adding a firewall to a server 

To add a firewall to a server, follow the steps in [Getting Started](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-getting-startedgetting-started). If you receive an error, see the [Known Limitations](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-known-limitations-with-hardware-firewall-shared-known-limitations-with-hardware-firewall-shared-) and [Getting help and support](https://cloud.ibm.com/docs/hardware-firewall-shared?topic=hardware-firewall-shared-getting-help-and-support-for-hardware-firewall-shared-getting-help-and-support-for-hardware-firewall-shared-).





 Editing rules 

When a firewall is first added to a server, a set of rules is initially put in place that allows all traffic to reach the server. The rules can then be edited to control the traffic reaching the server.

Ensure the "status" indicates that the firewall is "Processing All Rules." Users can choose to bypass the rules in the event that implemented rules have an unintended impact on their environment by clicking Bypass Rules in the Actions drop-down.



1. From your browser, open the [IBM Cloud catalog](https://cloud.ibm.com) and log into your account.
2. Select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) from the top left, then click Classic Infrastructure.
3. Select Devices > Device List and click on the firewall protected device you want to configure.
4. In the Add-ons section, click Firewall details.
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} authentication remote-id {{ secondary_peer_address }}
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} vti bind vti2
Show more

The VTI IP address 169.254.0.6 is an example. You can use any other unused IP address.
6. Create the primary route:

set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.5 distance 20
set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.5 interface vti2









 Troubleshooting 



* If you enable CPP firewall on Vyatta, you must configure the rules to allow traffic from IBM gateway. For example, if your CPP firewall name is GATEWAY_CPP, add these rules to the firewall:

 set security firewall name GATEWAY_CPP rule 250 source address 169.61.247.167
 set security firewall name GATEWAY_CPP rule 250 action accept
* If you are applying the firewall to the interface, you must permit the traffic from IBM VPC. For example:

 set security firewall name to-vpc rule 20 destination address 10.240.0.0/24
 set security firewall name to-vpc rule 20 action accept
 set security firewall name from-vpc rule 20 source address 10.240.0.0/24
 set security firewall name from-vpc rule 20 action accept
 set interfaces bonding dp0bond0 vif 862 firewall out to-vpc
 set interfaces bonding dp0bond0 vif 862 firewall in from-vpc

You might need to add other rules according to your network requirement to allow other traffic.
* UI
* API







 Protecting TCP traffic (Range) 

The Range feature brings DDoS protection, load balancing, and content acceleration to any TCP-based protocol. Range is a global TCP proxy running on IBM Cloud® Internet Services (Cloudflare) edge nodes.

Range can be used to:



* Protect your TCP ports and protocols from Layer-3 and Layer-4 DDoS attacks.
* Protect your HTTP(S) Range app with Layer-7 [firewall rules](https://cloud.ibm.com/docs/cis?topic=cis-about-firewall-rules).
* Reduce the ability of attackers to snoop and steal sensitive data by enabling TLS encryption.
* Integrate with CIS IP firewall, which allows you to block or challenge IP addresses, or entire IP ranges, from reaching your TCP services.
* Configure load balancers with TCP health checks, failover, and steering policies to dictate where traffic flows.



Range is only available to Enterprise customers for an additional cost, and is priced per bandwidth usage.



 Range limitations 

You can create a maximum of 10 Range applications with unique origins. Each Range application with a unique origin must have a unique IP address allocated, and IP addresses are a limited resource. If you need more than 10 Range applications, open an IBM Support case. Support cases to add more Range applications require a review of the use case, and the process can take a few days.

You can create more than 10 applications if they reuse an existing origin, but use different ports.

For TCP Range apps, only IP rules apply. This is because IP rules are applied to OSI Layer 3 and Layer 4. However HTTP(S) Range apps work with both firewall rules and IP rules. In general, firewall rules are designed for properties exposed in OSI Layer 7 (HTTP), such as request headers and body content characteristics.





 Adding an application using the console 

Follow these steps to add an application using the UI.

In the console, UDP applications must be enabled through a Support case. After the functionality is enabled, you can create a UDP application through the CLI or API.



1. Navigate to Security > Range.
Request for Extension Client requested an extension on the two-week connection time. 
 Request for Return Client requested the return of hardware. 
 Disconnect Disconnection of hardware was initiated. 
 Disconnected Target is safely detached. 
 Destroyed The device was destroyed on site by following the IBM Cloud® HDD destruction procedure. 
 Return by SoftLayer Hardware was packaged and shipped to the return address provided in the original request. 



* Can I mount DTS on VMware® ESXi servers?

IBM Cloud® does not support mounting a DTS device on a VMware® VCenter server. You can attach the DTS device to Linux® and Windows® operating systems.



Object Storage



* What types of authentication can I use to access IBM Cloud® Object Storage?

You can use an OAuth 2 token or an HMAC key for authentication. The HMAC key can be used for S3-compatible tools such as rclone, Cyberduck, and others.



* For instructions to obtain an OAuth token, see [Generating an IBM Cloud IAM token by using an API key](https://cloud.ibm.com/docs/account?topic=account-iamtoken_from_apikey).
* For instructions to obtain the HMAC credentials, see [Using HMAC Credentials](https://cloud.ibm.com/docs/cloud-object-storage/hmac?topic=cloud-object-storage-uhc-hmac-credentials-main).



Also, see [API Key vs HMAC](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-service-credentialsservice-credentials-iam-hmac).
* How do cross-origin resource sharing (CORS) and a bucket firewall differ in limiting access to data?

CORS allows interactions between resources from different origins that are normally prohibited. A bucket firewall allows access only to requests from a list of allowed IP addresses. For more information on CORS, see [What is CORS?]