vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In your private firewall, open the port that you configured when you deployed the service to the private IP addresses for all the worker nodes to allow traffic to. To find the port, run kubectl get svc. The port is in the 30000-32767 range.

NLB v1.0
: Load-balancing method: Basic load balancing that exposes the app with a private IP address.
: Use case: Quickly expose one app to a private network with a private IP address.
: Implementation: 1. [Create a private NLB service](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer). 2. In your private firewall, open the port that you configured when you deployed the service to the NLB's private IP address.

NLB v2.0
: Load-balancing method: DSR load balancing that exposes the app with a private IP address.
: Use case: Expose an app that might receive high levels of traffic to a private network with an IP address.
: Implementation: 1. [Create a private NLB service](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer). 2. In your private firewall, open the port that you configured when you deployed the service to the NLB's private IP address.

Ingress ALB
: Load-balancing method: HTTPS load balancing that exposes the app with a subdomain and uses custom routing rules.
: Use case: Implement custom routing rules and SSL termination for multiple apps.
: Implementation: 1. Configure a [DNS service that is available on the private network](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/). 2. [Enable the private ALB and create an Ingress resource](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup). 3. In your private firewall, open port 80 for HTTP or port 443 for HTTPS to the IP address for the private ALB.
Subnet ranges for Git 

You can update your firewall configuration to allow webhook messages from Git Repos and Issue Tracking to reach endpoints that are behind the firewall.

To allow Git webhook messages, open traffic to the following subnet ranges for your specific region.

au-syd
10.139.55.128/26
10.195.7.128/26
10.63.14.64/26
130.198.80.128/28
130.198.85.32/27
135.90.66.176/28
135.90.66.96/27
168.1.36.32/27
168.1.59.208/28
====
br-sao
10.14.14.0/26
10.15.17.0/26
10.150.99.64/26
163.107.68.48/28
163.107.70.96/27
163.109.70.160/28
163.109.70.192/27
169.57.162.64/27
169.57.175.144/28
====
ca-tor
10.11.30.0/26
10.114.28.192/26
10.243.29.0/26
158.85.67.192/27
163.74.68.224/28
163.74.69.64/27
163.75.66.144/28
163.75.68.0/27
169.53.183.48/28
====
eu-de
10.123.37.224/27
10.123.89.192/26
10.135.250.0/26
10.75.196.192/26
10.75.51.0/27
10.85.201.160/27
149.81.122.0/26
149.81.73.160/27
158.177.146.128/27
159.122.96.192/27
Managing your Informix on Cloud server 



 Logging in to your Informix on Cloud server 

Log in to your Informix on Cloud machine using an SSH client. Details are provided in a welcome email after your system is ready. Upon logging in the first time, you are immediately required to change your password.





 Administering your server 

IBM® Informix® on Cloud for IBM Cloud is based on IBM Informix Advanced Enterprise Server Edition.

You administer your Informix on Cloud Informix Server with the same utilities and tools that you use for your on-premises Informix Servers. See [Informix documentation](http://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.welcome.doc/welcome.htm) for the latest information about the Informix Server.

For instructions on how to successfully back up your Informix Server, please refer to the IBM Informix [Backup and Restore Guide](https://www.ibm.com/support/knowledgecenter/en/SSGU8G_14.1.0/com.ibm.bar.doc/bar.htm)





 Securing your Informix on Cloud server 

The IBM Informix on Cloud for IBM Cloud server is configured by default to allow SSH and SSL-based communication to occur only. Network access to the server is secured using the iptables firewall. Run this command to display the rules and status of the iptable firewall:

sudo iptables -L -n

If different settings are desired than the defaults, you have complete control to make these changes. For example, you can:



* Allow access to the server from a group of IP addresses only, also called a subnet. A subnet restricts access from users who are not part of the subnet. For example, the following rule allows incoming ssh connections from the 192.168.100.X network only:

iptables -A INPUT -i eth0 -p tcp -s 192.168.100.0/24 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
* Allow access through a single, approved IP address only. For example:
Disk 4.5 GB VMDK resident on shared storage with 4 GB swap 



The NSX Edges are configured as active or passive in either the internal or dedicated deployment. Therefore, the user must create the vSphere Distributed Resource Scheduler (DRS) anti-affinity rules to ensure that NSX Edges do not run on the same host as their respective peer appliance.



Table 2. NSX Edge anti-affinity rules

 Field Value 

 Name OpenShift-ESG 
 Type Separate virtual machines 
 Members OpenShift-ESG-0 <br>OpenShift-ESG-1 







 NSX ESG interfaces 

The edge is deployed with an interface uplink to the IBM Cloud Public network and an interface uplink to the IBM Cloud Private network. Additionally, an interface for the Transit network connection to the Distributed Logical Router (DLR) is available.



Table 3. Configuration for NSX Edge - interfaces

 Interface name Interface type IP address Port group / Logical switch 

 Private Uplink Uplink 10.208.242.130/26<br><br>10.208.242.131/26 SDDC-DPortGroup-Mgmt 
 Public Uplink Uplink 169.48.73.42/29 169.48.73.43/29 SDDC-DPortGroup-External 
 Transit Internal 192.168.100.1/24 OpenShift-Transit 







 NSX ESG firewall 

Configure rules to allow communication to the internet, to the IBM Cloud network, and into the VXLAN networks.



Table 4. Configuration for NSX Edge - NSX firewalls

 Firewall rule Source Destination Service Action 

 Private Outbound 10.208.242.128/26 Any Any Accept 
 Public Outbound 169.48.73.40/29 Any Any Accept 
 OpenShift Network 192.168.133.0/24 Any Any Accept 
 Transit Network 192.168.100.0/24 Any Any Accept 







 NSX ESG DHCP 

For the Red Hat OpenShift 4.7 environment, the bootstrap, control-plane, and compute nodes require access to a DHCP server to obtain an initial address on the network. The network provides access to download the bootstrap ignition file.
64 bytes from 172.16.100.1: icmp_seq=2 ttl=63 time=44.7 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=63 time=44.6 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=63 time=44.3 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=63 time=44.8 ms

--- 172.16.100.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4006ms

rtt min/avg/max/mdev = 44.377/44.728/44.996/0.243 ms

It is possible to either use the same VFP interface on multiple tunnels, or create different VFPs for other tunnels. Make sure that any additional VFPs are in a zone and have rules that allow the traffic for the unencapsulated frames.

It is also possible to add VFPs to their own zone. For example:

set security zone-policy zone SERVERS to TUNNEL firewall 'ALLOWALL'
set security zone-policy zone TUNNEL interface 'vfp0'
set security zone-policy zone TUNNEL to SERVERS firewall 'ALLOWALL'

A VFP interface is not a "real" interface in the way that dp0bond0 is (or even a VIF or TUN). It is a placeholder interface created by the firewall and NAT processes so that they can properly process traffic. You can still route traffic over a VFP like a regular interface, but tshark and other monitor commands reveal no traffic.
If services or servers are not contactable and nothing is seen in the firewall logs, verify if the expected ping/ssh IP traffic is present on the VRA network interface from the IBM Cloud private network or on the VRA interface to the VLAN using the <VLAN ID> from earlier.

monitor interface bonding dp0bond0 traffic
monitor interface bonding dp0bond0.<VLAN ID> traffic









 Step 6: Secure the VRA 



1. Apply VRA security policy. By default, policy-based firewall zoning does not secure access to the VRA itself. This is configured through Control Plane Policing (CPP). VRA provides a basic CPP rule set as a template. Merge it into your configuration:

configure
merge /opt/vyatta/etc/cpp.conf

This creates a new firewall rule set named CPP. View the additional rules and commit in [edit] mode.

show security firewall name CPP
commit
2. Securing public SSH access. Due to an outstanding issue at this time with the Vyatta firmware, it is not recommended to use set service SSH listen-address x.x.x.x to limit SSH administrative access over the public network. Alternatively, external access can be blocked via the CPP firewall for the range of public IP addresses used by the VRA public interface. The <VRA Public IP Subnet> used here is the same as the <VRA Public IP Address> with the last octet being zero (x.x.x.0).

set security firewall name CPP rule 900 action drop
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.
Getting started with Hardware Firewall 

The Hardware Firewall provides customers with an essential layer of security that is provisioned on demand without service interruptions. It prevents unwanted traffic from hitting your servers, reducing your attack surface, and allowing your server resources to be dedicated for their intended use.

To add a firewall to a server, perform the following procedure:



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 server you want protected.
4.  In the Device Details page, in the Configuration tab, scroll to the bottom of the page to the Addons section and click on the Order Hardware Firewall link.
5.  In the Order Hardware Firewall dialog, choose from the options presented (if applicable) and press Continue to complete the ordering process. The firewall speed will default to the speed of the public network interface of your server.
: If you use an IAM allowlist, you must [allow the CIDRs of the IBM Cloud Kubernetes Service control plane](https://cloud.ibm.com/docs/containers?topic=containers-firewall) for the zones in the region where your cluster is located so that IBM Cloud Kubernetes Service can create Ingress ALBs and LoadBalancers in your cluster.





 3 September 2019 

New! IBM Cloud Kubernetes Service plug-in version 0.4
: Updated the IBM Cloud Kubernetes Service CLI plug-in change log page for multiple changes in the [release of version 0.4.1](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog).

Version change log
: Worker node patch updates are available for Kubernetes [1.15.3_1516](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog1153_1516_worker), [1.14.6_1532](https://cloud.ibm.com/docs/containers?topic=containers-114_changelog1146_1532_worker), [1.13.10_1535](https://cloud.ibm.com/docs/containers?topic=containers-113_changelog11310_1535_worker), [1.12.10_1566](https://cloud.ibm.com/docs/containers?topic=containers-112_changelog11210_1566_worker), and Red Hat OpenShift [3.11.135_1523](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311135_1523_worker).







 August 2019 



 29 August 2019 

Forwarding Kubernetes API audit logs to IBM Log Analysis
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/teleport.pid

[Install]
WantedBy=multi-user.target
8. Issue the following systemctl to load the teleport service.

sudo systemctl daemon-reload
sudo systemctl start teleport
sudo systemctl enable teleport
9. Some operating systems have open firewalls but if your operating system limits traffic, you must add firewall rules to allow TCP traffic for ports 3023, 3024, 3025, and 3080. CentOS is an example of an operating system that blocks traffic by default.
10. Start the Teleport process systemctl start teleport.
11. Create a Teleport Role. For more information, see [Create Teleport Roles](https://goteleport.com/docs/enterprise/sso/oidc/create-teleport-roles). For more information on settings for a Teleport role, see [Teleport Access Control Reference](https://goteleport.com/docs/access-controls/reference/).



1. Create the file role.yaml within the directory /var/lib/teleport. The following sample role provides full access to the system. You can also create roles within the Teleport web console under Teams -> Roles.



example role
kind: "role"
version: "v3"
metadata:
name: "teleport-admin"
spec:
options:
max_connections: 3
cert_format: standard
client_idle_timeout: 15m
disconnect_expired_cert: no
enhanced_recording:
- command
- network
forward_agent: true
max_session_ttl: 1h
port_forwarding: false
allow:
logins: [root]
node_labels:
"": ""
rules:
- resources: [""]
* [Calico network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-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/openshift?topic=openshift-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 oc, and ibmcloud cr commands](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_bx), [oc commands](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_kubectl), and [calicoctl commands](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallfirewall_calicoctl) from your local system.



 Running ibmcloud, ibmcloud oc, 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 oc and ibmcloud cr commands, you must allow TCP access for IBM Cloud, Red Hat OpenShift on IBM Cloud, 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.
This port is the Veeam control channel that is used to communicate with the repository server.
* The firewall is started, enabled on startup, and enabled for logging.



- name: Enable firewalld on system reboot
service:
name: firewalld
enabled: yes

- name: Allow SSH
ansible.posix.firewalld:
service: ssh
permanent: yes
state: enabled

- name: Allow incoming access from the vbr server for management
ansible.posix.firewalld:
port: 6162/tcp
permanent: yes
state: enabled

- name: Reload firewall and enable firewall on boot
service:
name: firewalld
state: restarted
Show more





 Changing the DNS 

The following code snippet changes the DNS from the IBM Cloud® DNS resolvers - 10.0.80.11 and 10.0.80.12, with the vCenter Server instances DNS - addns1 and addns2.

- name: Change resolv nameserver_1
replace:
path: /etc/resolv.conf
regexp: "10.0.80.11"
replace: "{{ dns_1 }}"

- name: Change resolv nameserver_2
replace:
path: /etc/resolv.conf
regexp: "10.0.80.12"
replace: "{{ dns_2 }}"





 Finalizing the playbook 

Save the file. Ensure that the file is saved in the swlibansible directory on the automation server.





 Related links 



* [Cyber recovery with Veeam architecture overview](https://cloud.ibm.com/docs/vmwaresolutions/?topic=vmwaresolutions-veeam-cr-sa-overview)
* VPC: If you have a custom security group on the VPC LBaaS (LoadBalancer-as-a-Service) instances for the cluster ingress, ensure that the security group rules allow the necessary health-check traffic from the Kubernetes [control plane IP addresses](https://github.com/IBM-Cloud/kube-samples/tree/master/control-plane-ips) to port 443.



3. Check the health of your ALB IPs (classic) or hostname (VPC).



* For single zone cluster and multizone clusters: Ping the IP address (classic) or hostname (VPC) of each public ALB to ensure that each ALB is able to successfully receive packets. If you are using private ALBs, you can ping their IP addresses (classic) or hostname (VPC) only from the private network.

ping <ALB_IP>



* If the CLI returns a timeout and you have a custom firewall that is protecting your worker nodes, make sure that you allow ICMP in your firewall.
* If you don't have a firewall or your firewall does not block the pings and the pings still timeout, [check the status of your ALB pods](https://cloud.ibm.com/docs/containers?topic=containers-ingress-debugcheck_pods).



* Multizone clusters only: You can use the MZLB health check to determine the status of your ALB IPs (classic) or hostname (VPC). The following HTTP cURL command uses the albhealth host, which is configured by IBM Cloud Kubernetes Service to return the healthy or unhealthy status for an ALB IP.

curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"

Example command:

curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"

Example output

healthy
* [Using page rules with caching](https://cloud.ibm.com/docs/cis?topic=cis-use-page-rules-with-caching)
* [Using resolve override with Cloud Object Storage](https://cloud.ibm.com/docs/cis?topic=cis-resolve-override-cos)



* [Customizing error pages](https://cloud.ibm.com/docs/cis?topic=cis-custom-page)
* Using edge functions



* [Working with Edge functions](https://cloud.ibm.com/docs/cis?topic=cis-working-with-edge-functions)
* [Working with Edge functions actions](https://cloud.ibm.com/docs/cis?topic=cis-edge-functions-actions)



* Working with logs



* [Using the Logpull service](https://cloud.ibm.com/docs/cis?topic=cis-logpull)
* [Using the Logpush service](https://cloud.ibm.com/docs/cis?topic=cis-logpush)
* [Accessing log fields](https://cloud.ibm.com/docs/cis?topic=cis-log-fields)



* Working with metrics



* [Setting up GraphQL](https://cloud.ibm.com/docs/cis?topic=cis-graphql)
* [Querying Edge Functions metrics with GraphQL](https://cloud.ibm.com/docs/cis?topic=cis-graphql-edge-func)
* [Querying firewall events with GraphQL](https://cloud.ibm.com/docs/cis?topic=cis-graphql-firewall-events-example)



* Working with alerts



* [Configuring alert policies](https://cloud.ibm.com/docs/cis?topic=cis-configuring-policies)
choco install -y nxlog







 Configure NXLog 



1. Provision a syslog port for NXLog.

To get the required port value, do the following:



1. Access the [IBM Log Analysis UI.](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-launchlaunch_cloud_ui)
2. Click the ![question mark icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/question_mark.png) to access install instructions.
3. Click NXLog.
4. The syslog port you need to provision in Windows will be displayed. For example, syslog-a.us-south.logging.cloud.ibm.com:63980.



Then, in Windows, do the following:



1. From the Control Panel access System and Security > Windows Defender Firewall.
2. Click Advanced settings.
3. Click Inbound Rules.
4. Click New Rule.
5. Select Port.
6. Click Next.
7. For Specific local ports: enter 63980.
8. Click Next.
9. Select Allow the connection.
10. Click Next.
11. Select where the rule should apply.
12. Click Next.
13. Name the rule. For example, syslog-a.us-south.logging.cloud.ibm.com:63980.
14. Click Finish.



2. Create your nxlog.conf file.



1. Get the provided nxlog.conf file:



1. Access the [IBM Log Analysis UI.]
ip-set-on-public-ip-0 = {
description = "Public IP 0 - used for SNAT"
ip_addresses = []
address_target = "public-ip-0"
},
ip-set-on-public-ip-1 = {
description = "Public IP 1 - used for DNAT to app-server-1"
ip_addresses = []
address_target = "public-ip-1"
},
ip-set-on-public-ip-2 = {
description = "Public IP 2 - used for DNAT to jump-server-1"
ip_addresses = []
address_target = "public-ip-2"
},
ip-set-on-public-ip-3 = {
description = "Public IP 3"
ip_addresses = []
address_target = "public-ip-3"
},
ip-set-on-public-ip-4 = {
description = "Public IP 4"
ip_addresses = []
address_target = "public-ip-4"
},
ip-set-on-public-ip-5 = {
description = "Public IP 5"
ip_addresses = []
address_target = "public-ip-5"
},
ip-set-on-premises-networks = {
description = "On-premises networks"
ip_addresses = ["172.16.0.0/16",]
address_target = ""
},
}
Show more

You can also use Static Groups in firewall rules as sources and targets. 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"]
},
Vyatta 5400 common migration issues 

The following sections illustrate common issues or behavior changes you might encounter after migrating from a Vyatta 5400 device to a IBM Cloud® Virtual Router Appliance. In some cases, it includes workarounds to address the issues.



 Interface based global-state policy for stateful firewall 



 Issues 

The behavior when setting "state-of-state policy" for stateful firewalls from release 5.1 has been changed. In versions prior to release 5.1, if you set state -global -state -policy of a stateful firewall, the vRouter automatically added an implicit Allow rule for return communication of the session automatically.

In release 5.1 and later, you must add an Allow rule setting on the IBM Cloud® Virtual Router Appliance. The stateful setting works for interfaces on Vyatta 5400 devices, and for protocols on VRA devices.





 Workarounds 

If the firewall-in rule is applied on an ingress/inside interface, then you must apply the Firewall-out rule on the egress/outside interface. Otherwise, return traffic is dropped at the egress/outside interface.







 State-enable in firewall rules 



 State-enable issues 

If global-state-policy is not configured, this behavior change is not affected. Also, if you are using the state enable option in each rule instead of global-state-policy, the behavior change is not affected.







 Zone-based policy: Local-zone handling 



 Local-zone handling issues 

There is no "local-zone" pseudo-interface to assign to the zone-policy.





 Local-zone handling workarounds 

This behavior can be simulated by applying a zone-based firewall to physical interfaces, and an interface-firewall to the loopback interface. The firewall in the loopback interface filters everything that ingress and egress from the router.

For example:

set security zone-policy zone internal default-action 'drop'
set security zone-policy zone internal description 'Private zone'
set security zone-policy zone internal interface 'dp0bond0'
set security zone-policy zone internal to external firewall 'internal-2-external'