vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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
2. Create the SNAT rules on the VRA, specifying the same <Subnet Gateway IP>/<CIDR> as determined for the APP zone subnet/VLAN in the prior VRA provisioning tutorial.

set service nat source rule 1000 description 'pass traffic to the Internet'
set service nat source rule 1000 outbound-interface 'dp0bond1'
set service nat source rule 1000 source address <Subnet Gateway IP>/<CIDR>
set service nat source rule 1000 translation address masquerade
commit







 Step 3: Create Firewalls 



1. Create firewall rules for APP-TO-OUTSIDE

set security firewall name APP-TO-OUTSIDE default-action drop
set security firewall name APP-TO-OUTSIDE description 'APP traffic to the Internet'
set security firewall name APP-TO-OUTSIDE default-log

set security firewall name APP-TO-OUTSIDE rule 90 protocol tcp
set security firewall name APP-TO-OUTSIDE rule 90 action accept
set security firewall name APP-TO-OUTSIDE rule 90 destination port 80

set security firewall name APP-TO-OUTSIDE rule 100 protocol tcp
set security firewall name APP-TO-OUTSIDE rule 100 action accept
set security firewall name APP-TO-OUTSIDE rule 100 destination port 443

set security firewall name APP-TO-OUTSIDE rule 200 protocol icmp
set security firewall name APP-TO-OUTSIDE rule 200 icmp type 8
set security firewall name APP-TO-OUTSIDE rule 200 action accept
commit
Show more
2. Create firewall rules OUTSIDE-TO-APP
* [Context-based Restriction Rule APIs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule)







 Creating rules 

Context-based restrictions for the Direct Link service can be scoped to a Direct Link service resource type. The Direct Link Service has two applicable resource types: connect and dedicated.

Additionally, rules can be scoped to a specific instance of the service, or a resource group by using resource attributes.



 Creating rules by using the CLI 



1. To create rules from the CLI, [install the CBR CLI plug-in](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugininstall-cbr-plugin).
2. Use the [ibmcloud cbr rule-create command](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugincbr-cli-rule-create-command) to create CBR rules. For more information, see the CBR [CLI reference](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugincbr-zones-cli).



The examples in this section are enforcement rules. You can make them report-only by adding --enforcement-mode report.

The following example CLI commands create a context-based restriction rule for Direct Link service instances in the current account:



* Creates a report-only rule against all Direct Link Connect service instances in the current account:

ibmcloud cbr rule-create --description directlink-rule1 --service-name directlink --resource-type connect --zone-id=<zone_id> --enforcement-mode report
* Creates a disabled rule against all Direct Link Dedicated service instances in the current account that are in ResourceGroup x.

ibmcloud cbr rule-create --description directlink-rule2 --service-name directlink --resource-type dedicated --resource-attributes "resourceGroupId=<rg_x_id>" --zone-id=<zone_id> --enforcement-mode disabled
Add one Inbound rule: Set Protocol to TCP, Port Min and Max to 22, and Source Type to Any.
4. Add one Outbound rule: Set Protocol to All and Destination type to Any.



5. Create the security group vpc-region1-ui-sg:



1. Set the VPC to vpc-region1
2. Select your Resource Group
3. Add three Inbound rules:



* Set Protocol to TCP, Port Min and Max to 22, and Source Type to Any.
* Set Protocol to TCP, Port Min and Max to 80, and Source Type to Any.
* Set Protocol to TCP, Port Min and Max to 443, and Source Type to Any.



4. Add one Outbound rule: set the Protocol to All and Destination type to Any.



6. Create security groups for app and db. Use these guidelines:



* Allow SSH (port 22) for bastion access.
* If web access is required, then use HTTPS (port 443) for secure communication.
* Add any additional specific ports required for the respective tiers. *Avoid allowing all. Instead, create an allow list.









 Step 4: Create placement groups 

There are different approaches and strategies when it comes with placement groups. You can create a placement group per zone, per tier, per stack and so forth. For this example, create 2 placement groups, one placement group each for ui and application. The placement group spans the availability zones.



1. Go to Placement groups.
2. Click Create.
3. Enter web-group1 as the placement group unique name.
4. Select your Resource Group.
5. Select your Region.
6. Select Host spread as your Placement strategy.
7. Click Create placement group.
8. Repeat steps 2-7 for app-group1.







 Step 5: Create virtual server instances 

You create multiple virtual server instances in different availability zones for ui, application, db.



 Provision Bastion (jumphost) virtual server instance 

Use this task to provision the Bastion virtual server instance:
* Rules are stateful, therefore, reverse traffic in response to the permitted traffic is automatically permitted.
* Security groups are scoped to a single VPC.
* If you have multiple virtual servers in a security group, traffic between servers still need to be permitted.



For more information, see [About security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groups).





 Access Control Lists 

Access Control Lists (ACL) control all incoming and outgoing traffic to and from VPC subnets, rather than a security group which control traffic to and from virtual server instances.



* An ACL is stateless, so both inbound and outbound rules must be specified separately and explicitly.
* Each ACL consists of rules, based on a source IP, source port, destination IP, destination port, and protocol.
* A subnet can only have one ACL attached to it at any time, but one ACL can be attached to multiple subnets.
* Rules are processed in sequence.
* Every VPC has a default ACL that allows all inbound and outbound traffic.







 Securing Microsoft Windows Server 

Center for Internet Security (CIS) benchmarks are configuration baselines and best practices for securely configuring a system and references one or more CIS controls. CIS controls map to many established standards and regulatory frameworks, including the NIST Cybersecurity Framework (CSF) and NIST SP 800-53, the ISO 27000 series of standards, PCI DSS, HIPAA, and others. Refer to [Securing Microsoft Windows Server](https://www.cisecurity.org/benchmark/microsoft_windows_server/) for information on hardening the Windows OS and [Securing Microsoft SQL Server](https://www.cisecurity.org/benchmark/microsoft_sql_server/) for information on hardening MS SQL 2019.





 Windows server patching 

There are no Microsoft update servers on the the IBM Cloud VPC network, therefore, access to the Microsoft repositories via the Internet is required. This can be achieved by:
If an address has multiple NAT rules, the rule with the highest priority is applied.

When configuring NSX-T NAT in IBM Cloud VPC, you can use the public /32 floating IP addresses as the public NAT IP addresses in both Tier-0 and Tier-1 Logical Routers. You can have multiple NAT IPs, if needed. When NAT is configured on Tier-1 Logical Router, ensure that the floating IP is correctly advertised between Tier-0 and Tier-1 Logical Routers.

For more information on NAT in NSX-T, see [VMware Documentation](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-7AD2C384-4303-4D6C-A44A-DEF45AA18A92.html).





 Firewall 

You can configure East-West and North-South firewall policies in your NSX-T platform.

Gateway firewall represents rules that are applied to the perimeter firewall for North-South traffic connected to IBM Cloud VPC. Gateway firewall can be applied to both Tier-0 and Tier-1 Logical Routers.

Distributed firewall monitors all the East-West traffic on your VMs. Grouping of objects simplifies rule management. Groups include different objects that are added both statically and dynamically, and can be used as the source and destination of a firewall rule. They can be configured to contain a combination of VMs, IP sets, MAC sets, segment ports, segments, AD user groups, and other groups. Dynamic inclusion of groups can be based on tag, machine name, OS name, or computer name.

For more information on Firewalls in NSX-T, see [VMware Documentation](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-F206A4B8-0F33-482D-8727-E71FE253BBCD.html).







 Related links
Each ACL consists of rules, based on a source IP, source port, destination IP, destination port, and protocol.

Every VPC has a default ACL that allows all inbound and outbound traffic. You can edit the default ACL rules, or create a custom ACL and attach it to your subnets. A subnet can only have one ACL attached to it at any time, but one ACL can be attached to multiple subnets. For more information about how to use ACLs, see [Setting up network ACLs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-acls).





 Security groups 

A security group acts as a virtual firewall that controls the traffic for one or more virtual server instances. A security group is a collection of rules that specify whether to allow or deny traffic for an associated instance. You can associate an instance with one or more security groups and edit the security group rules. For more information, see [Using security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groups).





 Comparing security groups and access control lists 

Table 1 summarizes some key differences between security groups and ACLs.



Table 1. Differences between security groups and ACLs

 Security Groups ACLs 

 Control level Virtual server instance Subnet 
 State Stateful - When an inbound connection is permitted, it is allowed to reply Stateless - Both inbound and outbound connections must be explicitly allowed 
 Supported rules Uses allow rules only Uses allow and deny rules 
 How rules are applied All rules are considered Rules are processed in sequence 
 Relationship to the associated resource An instance can be associated with multiple security groups Multiple subnets can be associated with the same ACL 







 End-to-end encryption 

Although IBM Cloud VPC doesn't provide end-to-end encryption, it allows for it. For example, if you have a secure endpoint on a virtual server instance (such as an HTTPS server on port 443), you can attach a floating IP to that instance, and then your connection is end-to-end encrypted from the client to the server on port 443. Nothing in the path forces a decryption.
Enterprise only: You can also instruct CIS not to override browser cache control by setting this to Respect Existing Headers.





 Using Development mode 

Development mode is intended for use when major updates or new file uploads are required, or any time you do not want the end users to work from the cache at all, but to retrieve files directly from the origin servers. To begin using Development Mode, toggle the switch to Enabled position. To stop using Development Mode, toggle the switch to Disabled position. Development mode expires automatically after 3 hours.





 Managing page rules 

You can use page rules to specify particular settings that only apply to certain URLs, for example to have different cache control settings for certain URL paths. Use the list menus to configure the page rule. The rule settings are divided into three categories: Security, Performance, and Reliability.

Notice that when certain rules are enabled, other options become grayed out, if those options are in conflict with the other rules you've just selected. After you've selected the page rules that you want, click Provision to enable them. The new rules take effect immediately, and they can be viewed immediately on the Page Rules screen.

You also can enable or disable your page rules from the table displayed in the Page Rules screen. See [Using page rules](https://cloud.ibm.com/docs/cis?topic=cis-use-page-rules) for details.





 Security settings 

By default, DDoS protection is enabled for any DNS records or load balancers with proxy on.

Only proxied records result in traffic being routed through CIS cloud edge for edge processing.

Security settings are:



* Turn on WAF using the toggle on the Web Application Firewall page. When you toggle the rules on or off, the changes are applied immediately.
* Enterprise only - The Rate limiting page allows you to configure rate limiting rules to avoid noisy-neighbor problems and ward off DDoS.
* On the IP Firewall page, you can configure access rules based on IP, country code, or ASN. You can also configure rules to block user agents.
* Public endpoints can accept requests from anywhere.
* Private endpoints are available for most requests, that originate from within IBM Cloud®.
* Direct endpoints are used in Bring-Your-Own-IP scenarios, generally for requests, that originate from resources within VPCs.



Some endpoint types might not be supported by the selected service.







 Access requirements 

To complete rule actions, you must be assigned an IAM policy on the target service. To complete network zone actions, you must be assigned an IAM policy on the context-based restrictions service.

To create a context-based restriction for a service, you must be assigned an IAM policy with the Administrator role the service you are creating a rule against. For example, if you want to create a rule to protect a Key Protect instance, you must be assigned the Administrator role on the Key Protect service and the Viewer role or higher on the Context-based restrictions** service.

The Viewer role on the Context-based restrictions service authorizes you to add network zones to your rule.



 Context-based restrictions roles and actions 

To manage network zones, you must be assigned an IAM policy with a specific role for the Context-based restrictions account management service. The following table shows the possible access roles and actions for account management.



Table 2. Roles and actions for the Context-based restrictions service

 Roles Actions 

 Viewer View network zones 
 Editor View network zones<br><br>Create network zones<br><br>Update network zones<br><br>Remove network zones 
 Administrator View network zones<br><br>Create network zones<br><br>Update network zones<br><br>Remove network zones 



For more information, see [Actions and roles for account management services](https://cloud.ibm.com/docs/account?topic=account-account-services&interface=ui).

You can also use network zones to restrict access at the account level. To set account-level restrictions by using network zones, go to Manage > IAM > Settings in the IBM Cloud console and enter the name of your network zone.





 Target service roles and actions 

To manage rules, you must be assigned an IAM policy with the Administrator role for the service that you are creating the rule against.
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.

You might find that some rules impact the comfort of administrating resources, e.g., through the browser console. Moreover, you need to make sure that you don't deny yourself access to resources, management dashboards and APIs. Thus, you have to account for bastion hosts, corporate networks, gateways and maybe even Cloud Shell. In addition, some services support a fine-grained distinction of data plane and control place access for CBR configuration, e.g., [Kubernetes Service cluster and management APIs](https://cloud.ibm.com/docs/containers?topic=containers-cbrprotect-api-types-cbr).

In summary, these questions should be asked:



* Are all resources protected by IAM and similar?
* How are the resources accessed, are they already limited to private endpoints where possible?
* Is it possible to separate data plane and control plane access?
* What is traffic related to usage, which to administrative work? How are emergencies handled?
* From where does the above traffic originate?



Use the report mode to be aware of activities matching the context-based restrictions. Do the rule-based decisions render a permit or deny? Does that match your expectation? To learn about activities and to handle them correctly with CBR rules, a test phase in reporting mode of at least a month is recommended. This allows for an iterative approach towards the desired set of network zones and context rules.

For this tutorial, we are going to define the following network zones:



* a zone for each of the deployed services which are supported as service reference for originating traffic
* a zone for each for the Kubernetes cluster
For example, you can create the following set of ACL rules to block most inbound and outbound network traffic of a cluster, while allowing communication that is necessary for the cluster to function.

Limitations
: If you create multiple clusters that use the same subnets in one VPC, you can't use ACLs to control traffic between the clusters because they share the same subnets. You can use [Calico network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesisolate_workers) to isolate your clusters on the private network.

When you use the following steps to create custom ACLs, only network traffic that is specified in the ACL rules is permitted to and from your VPC subnets. All other traffic that is not specified in the ACLs is blocked for the subnets, such as cluster integrations with third party services. If you must allow other traffic to or from your worker nodes, be sure to specify those rules where noted in the following steps.

For more information, see the [VPC documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-using-acls).



 Creating ACLs from the console 

For each subnet that your cluster is attached to, use the IBM Cloud VPC console to create a custom ACL with rules that limit inbound and outbound network traffic to only communication that is necessary for the cluster to function.

Looking for a simpler security setup? Leave the default ACL for your VPC as-is, and modify the [default security group](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group) instead.



1. 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.
Then, click Create.



Xander is logging and monitoring policy management requests by using report-only mode. Since the management team has the right access policies and use allowed IP addresses, they are authorized to execute policy management operations. All policy management requests that come from IP addresses that don't match the conext that Xander defined are denied when the rule is enabled.





 Next steps 

After 30 days of monitoring, update the rule to Enabled to begin enforcing your restrictions.

You can also use network zones to restrict access at the account level and user level. For more information, see [Allowing specific IP addresses](https://cloud.ibm.com/docs/account?topic=account-ips&interface=ui).

To create context-based restrictions programmatically, see the [Context-based Restrictions API](https://cloud.ibm.com/apidocs/context-based-restrictions) and the [Context-based restrictions CLI plug-in](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugin).

For more information about implementing context-based restrictions in your security strategy, see the solution tutorial [Enhance cloud security by applying context-based restrictions](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-cbr-enhanced-security).
About network ACLs 

You can use an access control list (ACL) to control all incoming and outgoing traffic in IBM Cloud® Virtual Private Cloud. An ACL is a built-in, virtual firewall, similar to a security group. In contrast to security groups, ACL rules control traffic to and from the subnets, rather than to and from the instances.

For a comparison of the characteristics of security groups and ACLs, see the [comparison table](https://cloud.ibm.com/docs/vpc?topic=vpc-security-in-your-vpccompare-security-groups-and-access-control-lists).

The example that is presented in this document shows how to create network ACLs in your VPC by using the CLI. For more information about how to set up ACLs in the IBM Cloud console, see [Configuring ACLs in the UI](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-consoleconfiguring-the-acl-ct).



 Working with ACLs and ACL rules 

To make your ACLs effective, create rules that determine how to handle your inbound and outbound network traffic. You can create multiple inbound and outbound rules. For more information about rules quotas, see [Quotas](https://cloud.ibm.com/docs/vpc?topic=vpc-quotasacl-quotas).



* With inbound rules, you can allow or deny traffic from a source IP range, with specified protocols and ports.
* With outbound rules, you can allow or deny traffic to a destination IP range, with specified protocols and ports.
* ACL rules are prioritized and considered in sequence. Higher priority rules are evaluated first and override lower priority rules.
* Inbound rules are separated from outbound rules.
* If no rules are specified, then implicit deny is the default behavior.
set firewall name PRIV_SERVICE_IN rule 58 destination address '10.150.156.57'
set firewall name PRIV_SERVICE_IN rule 58 destination port '3306'
set firewall name PRIV_SERVICE_IN rule 58 protocol 'tcp'
set firewall name PRIV_SERVICE_IN rule 58 source address '10.150.156.104'
set firewall name PRIV_SERVICE_IN rule 58 time startdate '2017-08-22'
set firewall name PRIV_SERVICE_IN rule 58 time stopdate '2018-02-22'







 TCP-MSS 



 TCP-MSS issues 

set interfaces tunnel tun3 address '172.17.175.45/30'
set interfaces tunnel tun3 encapsulation 'gre'
set interfaces tunnel tun3 local-ip '169.55.223.76'
set interfaces tunnel tun3 mtu '1476'
set interfaces tunnel tun3 multicast 'disable'
set interfaces tunnel tun3 policy route 'change-mss'(in 18.x unable to apply tcp-mss using PBR only option is to set on interface directly which i believe is not equivalent to pbr .
set interfaces tunnel tun3 remote-ip '104.129.200.34'

set policy route change-mss rule 1 protocol 'tcp'
set policy route change-mss rule 1 set tcp-mss '1436'
set policy route change-mss rule 1 tcp flags 'SYN







 Specific application or port broken in S-S IPsec VPN 



 Specific application or port broken in S-S IPsec VPN issues 

vyatta@v5600dallas09 set security vpn ipsec site-to-site peer 12.0.0.1 tunnel 1 remote
Possible Completions:
<Enter> Execute the current command
port Any TCP or UDP port
prefix Remote IPv4 or IPv6 prefix set security vpn ipsec esp-group ESP lifetime '30000'
set security vpn ipsec esp-group ESP proposal 1 encryption 'aes128'