Networking

In the Networking pane, you configure security and routing services for your IaaS.
To configure the Networking pane:

Gorouter IPs

For Gorouter IPs, see the guidance below:

• For AWS, Azure, and GCP, leave these fields blank. You do not need to configure these fields when deploying TAS for VMs on these infrastructures.
• For OpenStack and vSphere, use the table below to determine how to configure this field:

Important If you choose to assign specific IP addresses in the Gorouter IPs field, ensure that these IP addresses are in the subnet that you configured for TAS for VMs in Tanzu Operations Manager.

Gorouter IPs field
1. Choose IP addresses from the subnet you configured in Tanzu Operations Manager.
2. Enter these IP addresses in Gorouter IPs. You should specify more than one IP address for high availability. The IP addresses must be within your subnet CIDR block.
3. Configure your load balancer to forward requests for the domains that you have configured for your deployment to these IP addresses.

SSH proxy IPs and TCP router IPs

For SSH Proxy IPs and TCP router IPs, see the guidance below:

• For AWS, Azure, and GCP, leave these fields blank. You do not need to configure these fields when deploying TAS for VMs on these infrastructures.

• For OpenStack and vSphere:

  • (Optional) In SSH Proxy IPs, add the IP address for your Diego Brain, which accepts requests to SSH into app containers on port 2222.
  • (Optional) In TCP router IPs, add the IP addresses you want to assign to the TCP routers. You configure TCP routing at the bottom of this pane.

Important If you configure mutual TLS app identity verification, app containers accept incoming communication only from the Gorouter. This deactivates TCP routing.

Certificates and private keys for the Gorouter

Under Certificates and private keys for the Gorouter, you must provide at least one certificate and private key pair for the Gorouter. The Gorouter is configured to receive TLS communication by default. You can configure multiple certificates for the Gorouter.

Important When providing custom certificates, enter them in this order: wildcard, Intermediate, CA. For more information, see the DigiCert documentation.

1. To configure a certificate and private key for the Gorouter:
   1. Click Add. The Gorouter uses the certificate you configure as the default certificate.
   2. For Name, enter a human-readable name that describes the use of this certificate.
   3. For Certificate and private key, choose one of the following options:
      • Enter a certificate signed by a Certificate Authority (CA).
      • Click Generate RSA Certificate. Clicking this link causes the Tanzu Operations Manager CA to automatically generate a certificate.
      For the values to use, see Providing a Certificate for your TLS termination point.

      Note If you configured your Tanzu Operations Manager front end without a certificate, you can use this new certificate to finish configuring Tanzu Operations Manager. To configure your Tanzu Operations Manager front end certificate, see the Tanzu Operations Manager documentation.

2. (Optional) To configure multiple certificates for the Gorouter:
   1. For each additional certificate and key pair, click Add.
   2. Configure the fields you configured for the first certificate and key pair in the previous step. For more information about generating certificates in Tanzu Operations Manager for your wildcard system domains, see Providing a Certificate for Your TLS Termination Point.

Important Ensure that you add any certificates that you generate in this pane to your infrastructure load balancer.

CA certificates for Gorouter

(Optional) When validating requests using mutual TLS to back ends and route services, the Gorouter trusts multiple CAs by default. To configure which CA certificates Gorouter trusts, choose one of the following options:

• For backwards compatibility with older versions of Isolation Segment:
  1. Under Trusted CAs for client requests, select Trust the same CAs used for back ends and route services.
• If you want the Gorouter to trust a particular set of CAs only:
  1. Under Trusted CAs for client requests, select Only trust the following CAs.
  2. For Trusted client CAs, enter the CAs you want the Gorouter to trust. The CAs you provide in this field are the only CAs that the Gorouter trusts for client requests. The Gorouter does not trust any well-known CAs that are provided with the stemcell.

Trusted CA certificates

(Optional) When validating client requests using mutual TLS, the Gorouter trusts multiple certificate authorities (CAs) by default. For Trusted CA certificates, enter your CA certificates appended together into a single collection of PEM-encoded entries.

HTTP/2 protocol

(Optional) The Use HTTP/2 protocol check box is selected by default. When this check box is selected, the Gorouter accepts all incoming HTTP/2 requests and sends HTTP/2 requests over app routes that support HTTP/2. To deactivate HTTP/2 ingress and egress for the Gorouter, deselect the Use HTTP/2 protocol check box. For more information about HTTP/2 routing, see Supporting HTTP/2.

Deselecting the Use HTTP/2 protocol check box introduces potential breaking changes for app routes.

Enable concurrent reads/writes for HTTP/1

(Optional) To enable concurrent request reads and response writes for HTTP/1 requests in the Gorouter, select the Enable concurrent reads/writes for HTTP/1 check box. By default, the Gorouter consumes any unread portion of the request body before beginning to write the response, preventing handlers from concurrently reading from the request and writing the response. Selecting this check box deactivates that behavior and permits handlers to continue to read from the request while concurrently writing the response. ## TLS versions Under TLS versions, select the range of TLS versions to use in Gorouter communications. The Gorouter supports TLS v1.2 to TLS v1.3 by default. If you need to accommodate clients that use an older version of TLS, select a lower minimum version. For a list of TLS ciphers supported by the Gorouter, see TLS cipher suite support in Securing traffic into TAS for VMs. ## Load balancing algorithm (Optional) Under Load balancing algorithm, select either Round-robin or Least-connection as your load balancing algorithm for the Gorouter. Round-robin is selected by default, and VMware recommends this option for most use cases. Some use cases, such as those where apps have long-lived connections, might benefit from the least-connection algorithm. For more information, see Router balancing algorithm in HTTP Routing.

(Optional) Under Load balancing algorithm availability zone preference, select either None or Locally-optimistic as the availability zone preference for the Gorouter's load balancing algorithm. None is selected by default, and VMware does not recommend changing it. For more information, see Load balancing availability zone preference in HTTP Routing. ## Client IP logging Under Client IP logging, Log client IPs is selected by default. To comply with the General Data Protection Regulation (GDPR), select one of the following options:

• If your load balancer exposes its own source IP address, select Do not log X-Forwarded-For header.
• If your load balancer exposes the source IP address of the originating client, select Do not log source IP or X-Forwarded-For header.

TLS termination point

Under TLS termination point, configure how TAS for VMs handles x-forwarded-client-cert (XFCC) HTTP headers based on where TLS is terminated for the first time in your deployment. The table below indicates which option to choose based on your deployment configuration:

<table>
<thead>
    <tr>
        <th>Deployment configuration</th>
        <th>TLS option</th> 
        <th>Additional notes</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>
            <ul>
            <li>The load balancer is terminating TLS, and</li>
            <li>The load balancer is configured to put the client certificate from a mutual authentication TLS handshake into the X-Forwarded-Client-Cert HTTP header.
            </li>
            </ul>
        </td>
        <td>Infrastructure load balancer</td>
        <td>The Gorouter forwards the XFCC header when included in the request.</td>
    </tr>
    <tr>
        <td>
            <ul>
            <li>The load balancer is configured to pass through the TLS handshake through TCP to instances of the Gorouter</li>
            </ul> 
        </td>
        <td>Gorouter</td>
        <td>The Gorouter strips the XFCC header if it is included in the request and forwards the client certificate received in the TLS handshake in a new XFCC header.
        <br/><br/>
        <p class="note caution"><span class="note__title">Caution</span>If you select the <strong>The Gorouter does not request client certificates</strong> option in the <strong>Gorouter behavior for client certificate validation</strong> field, the XFCC header cannot be delivered to apps.</p>
        </td>
    </tr>
</tbody>
</table>

For a description of the behavior of each configuration option, see Forward Client Certificate to Apps in HTTP Routing.

Gorouter behavior for client certificate validation

To configure Gorouter behavior for handling client certificates, select one of the following options under Gorouter behavior for client certificate validation:

• The Gorouter does not request client certificates: The Gorouter does not request client certificates, so the client does not provide them, and the Gorouter does not validate them. This option is incompatible with configuring the Gorouter as your TLS termination point, which requires mutual authentication.
• The Gorouter requests but does not require client certificates: The Gorouter requests client certificates in TLS handshakes and validates them when they are presented, but does not require them. This option is configured by default.
• The Gorouter requires client certificates: The Gorouter validates that the client certificate is signed by a Certificate Authority (CA) that the Gorouter trusts. If the Gorouter cannot validate the client certificate, the TLS handshake fails.

Requests to the platform fail upon upgrade if your load balancer is configured with client certificates and the Gorouter is not configured with the appropriate CA. To mitigate this issue, select The Gorouter does not request client certificates.

TLS cipher suites for the Gorouter

In the TLS cipher suites for the Gorouter field, review the TLS cipher suites for TLS handshakes between the Gorouter and front end clients such as load balancers. The default value for this field is ECDHE-RSA-AES128-GCM-SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

To modify the default configuration, use an ordered, colon-separated list of Golang-supported TLS cipher suites in the OpenSSL format. This field does not apply to TLS v1.3. For TLS v1.3, the Gorouter only uses a set of default ciphers, and this is not configurable.

Verify that the ciphers are supported by any clients or front end components that initiate TLS handshakes with the Gorouter. For a list of TLS ciphers supported by the Gorouter, see TLS Cipher Suite Support in Securing Traffic into TAS for VMs.

Verify that every client participating in TLS handshakes with the Gorouter has at least one cipher suite in common with the Gorouter.

Important Specify cipher suites that are supported by the versions configured under Select the range of TLS versions supported by the Gorouter. For example, TLS v1.3 does not support configuring cipher suites. If you select TLSv1.3 only, you cannot configure cipher suites for the Gorouter.

AWS Classic Load Balancers do not support the TAS for VMs default cipher suites. For more information about configuring your AWS load balancers and Gorouter, see TLS Cipher suite support by AWS load balancers in Securing traffic into TAS for VMs.

Reject HTTP requests

(Optional) If you want the Gorouter to reject any unencrypted traffic, select the Reject HTTP requests check box. When this check box is selected, the Gorouter does not listen on port 80.

Do not use insecure cookie

(Optional) To configure the Gorouter to only generate secure cookies, select the Do not use insecure cookies check box.

Enable Zipkin tracing headers on the Gorouter

(Optional) To deactivate the addition of Zipkin tracing headers on the Gorouter, deselect the Enable Zipkin tracing headers on the Gorouter check box. Zipkin tracing headers are enabled by default. For more information about using Zipkin trace logging headers, see HTTP headers for zipkin tracing in HTTP routing.

W3C tracing headers on the Gorouter

(Optional) To activate the addition of W3C tracing headers on the Gorouter, select the Add W3C tracing headers check box. W3C tracing headers are disabled by default. Specify W3C tracing tenant ID name in W3C tenant ID field. If specified, the tracestate identifier will be "tenant-id@gorouter" where "tenant-id" is the value specified. If not specified, the tracestate identifier will be gorouter. For more information about using W3C trace logging headers, see HTTP headers for W3C tracing in HTTP routing.

Allow the Gorouter to write access logs locally

(Optional) The Allow the Gorouter to write access logs locally check box is selected by default. VMware recommends deselecting this check box for high-traffic deployments, since logs might not be rotated fast enough and can fill up the disk.

Requests to isolation segments

Under Requests to isolation segments, select one of the following options:

• Accept requests for all isolation segments: TAS for VMs Gorouters accept all traffic for apps deployed to an isolation segment created by the Isolation Segment tile. This option is selected by default.
• Accept requests for some isolation segments: TAS for VMs Gorouters to only accept requests for apps within specific isolation segments. If you select this option, you must also enter the names of the isolation segments for which you want TAS for VMs Gorouters to accept requests as a comma-separated list in Isolation segment names.
• Reject requests for all isolation segments: TAS for VMs Gorouters reject requests for apps within all isolation segments.

For more information, see Installing Isolation Segment and Sharding Gorouters for isolation segments in Routing for isolation segments.

Accept PROXY requests

(Optional) By default, the Gorouter does not accept PROXY requests. To configure the Gorouter to accept PROXY requests, select the Accept PROXY requests check box. When you select this check box, client-side load balancers that stop TLS but do not support HTTP can pass along information from the originating client using the PROXY protocol. Configuring this option might impact Gorouter performance. For more information about configuring the Gorouter to accept PROXY requests, see the About HTTP header forwarding sections in Securing Traffic into TAS for VMs.

Route services

Under Route services, select either Allow or Do not allow. Route services are a class of marketplace services that perform filtering or content transformation on app requests and responses. For more information, see Route Services and List Marketplace Services in Managing service instances with the cf CLI.

• If you allow route services, you can also configure Bypass security checks for route service lookup. VMware recommends that you do not configure this field, due to potential security concerns. However, you might need to configure it if your load balancer requires mutual TLS from clients. For more information, see Configuring Route Service lookup.

Maximum connections per back end

(Optional) To limit the number of app connections to the back end, enter a value in Maximum connections per back end. Configuring this field allows you to prevent a poorly-behaving app from impacting other apps. To allow an unlimited number of app connections to the back end, enter either 0 or no value. The default value is 500.

To determine a value to configure in this field, review the highest number of concurrent connections that instances of the most popular apps in your deployment have received. You can determine the number of concurrent connections for an app by reviewing the httpStartStop event metrics emitted for each app request. If your deployment uses App Metrics, you can also find this information in your App Metrics deployment. For more information, see the App Metrics documentation.

Keep-alive connections

Under Keep-alive connections, select one of the following options:

• Allow: The Gorouter maintains TCP connections after receiving an HTTP response. This option is selected by default.
• Do not allow: The Gorouter closes TCP connections after receiving an HTTP response.

For more information, see Keep-alive connections in HTTP Routing.

Back end request timeout and idle timeout

(Optional) For Back end request timeout and idle timeout, enter in seconds the amount of time that requests between the Gorouter and apps are allowed to remain idle before being closed. The default value is 900. To accommodate larger uploads over connections with high latency, increase the value.

Query parameter logging in Gorouter access logs

(Optional) To configure whether the Gorouter shows or hides GET request query parameters in access logs, select one of the following options under Query parameter logging in Gorouter access logs:

• Log query parameters: The Gorouter logs all query paramaters without altering them.

CautionIf you select this option, GET request query parameters in Gorouter access logs might contain sensitive information.

• Log a hash of query parameters: The Gorouter hashes all query paramaters.
• Do not log query parameters: The Gorouter hides all query paramaters.

Front end idle timeout

(Optional) To help prevent connections from your load balancer to the Gorouter from being closed prematurely, configure the Front end idle timeout field. The value you enter sets the duration, in seconds, that the Gorouter maintains an idle open connection from a load balancer that supports keep-alive connections.

To avoid the race condition where the load balancer sends a request before it discovers that the Gorouter has closed the connection, enter a value that is higher than the back end idle timeout for your load balancer.

For specific guidance and exceptions to this rule, see the following table:

IaaS	Guidance
AWS	Because AWS ELB has a default timeout of 60 seconds, VMware recommends configuring a value greater than 60.
Azure	By default, the Azure load balancer times out at 240 seconds without sending a TCP RST to clients. To force the load balancer to send the TCP RST, VMware recommends configuring a value lower than 240.
GCP	GCP has a default timeout of 600 seconds. For GCP HTTP load balancers, VMware recommends configuring a value greater than 600. For GCP TCP load balancers, VMware recommends configuring a value less than 600 to force the load balancer to send a TCP RST.
Other	Configure a value greater than that of the back end idle timeout for your load balancer.

Note Do not set a front end idle timeout lower than six seconds.

(Optional) For Gorouter drain timeout, enter in seconds the amount of time that the Gorouter continues to serve existing connections before shutting down. After the timeout is reached, all remaining connections are terminated so the Gorouter can restart. To reduce the drain time during deployments, enter a value that is lower than the values in Back end request and idle timeout and Front end idle timeout. The default value is 900.

Load balancer unhealthy threshold

(Optional) Increase the value of Load balancer unhealthy threshold to specify the amount of time, in seconds, that the Gorouter continues to accept connections before shutting down. During this period, health checks might report the Gorouter as unhealthy, which causes load balancers to failover to other Gorouters. Configure a value that is greater than or equal to the maximum time it takes your load balancer to consider a Gorouter instance unhealthy, given repeated failed health checks.

Load balancer healthy threshold

(Optional) Modify the value of Load balancer healthy threshold. This field specifies the amount of time, in seconds, to wait until declaring the Gorouter instance started. This allows an external load balancer enough time to register the Gorouter instance as healthy.

HTTP headers to log

(Optional) If app developers in your organization want certain HTTP request headers to appear in their app logs with information from the Gorouter, enter them as a comma-separated list under HTTP headers to log. For example, to support app developers that deploy Spring apps to TAS for VMs, you can enter Spring-specific HTTP request headers.

The Gorouter always logs the following HTTP request headers:

• Referer
• User-Agent
• X-Forwarded-For
• X-Forwarded-Proto
• X-Vcap-Request-ID

Maximum request header size

For Maximum request header size, enter the maximum total size (in KB) that all headers in a request to the Gorouter might have combined, including header keys, header values, and all values in the request line. Configuring this field allows TAS for VMs to prevent denial-of-service attacks from requests with large headers.

Requests with headers that exceed this limit cause a 431 status code. Enter a value between 1 and 1024. VMware recommends configuring a limit of 48. To account for backwards compatibility, you can configure a higher limit, if required. Configuring this field does not limit the size of the request body.

Important If you do not configure Loggregator port, it defaults to 443. For AWS environments that are not using an Application Load Balancer, enter 4443.

Container network interface plugin

For Container network interface plugin, select one of the following options:

• Silk: The default container network interface (CNI) for TAS for VMs.
• External: Select this option if you are deploying the VMware NSX-T Container plug-in for TAS for VMs.
  If you select External, follow the procedure in Deploying TAS for VMs with NSX-T Networking in addition to the procedures in this topic.
  The NSX-T integration only works for new installations of TAS for VMs. If your TAS for VMs tile is already deployed and configured to use Silk as its CNI, you cannot re-configure your deployment to use NSX-T.

If you selected Silk in the previous step, review the following fields:

1. (Optional) For App network maximum transmission unit, enter an MTU value in bytes. The default value is 1454. Some configurations might require a smaller MTU value. For example, networks that use GRE tunnels might require a smaller MTU.
   For Azure environments, VMware recommends entering 1400 or lower to prevent Azure from fragmenting the packets. For more information, see the Azure documentation.

2. (Optional) For Overlay subnet, enter an IP range for the overlay network. If you do not set a custom range, Tanzu Operations Manager uses 10.255.0.0/16. The overlay network IP range you configure must not conflict with any other IP addresses in your network.
   Editing this property might cause container-to-container (C2C) networking downtime and security implications the next time you redeploy TAS for VMs.

3. For Overlay subnet prefix length per Diego Cell, enter in bits the length of the prefix for subnets allocated per Diego Cell. For example, for a /24 subnet, enter 24. The default value is 24. The minimum value you can configure is 2. The maximum value you can configure is 30. Configuring a smaller subnet allows more Diego Cells per TAS for VMs deployment, but fewer apps per Diego Cell. Conversely, configuring a larger subnet allows more apps per Diego Cell, but fewer Diego Cells per TAS for VMs deployment. The values that you configure in the Overlay subnet and Overlay subnet prefix length per Diego Cell fields determine the exact number of Diego Cells allowed per TAS for VMs deployment and apps allowed per Diego Cell.
   Editing this property might cause C2C networking downtime and security implications the next time you redeploy TAS for VMs.

4. In the VXLAN tunnel endpoint port field, enter a UDP port number. This is the host port that receives VXLAN packets. If you do not set a custom port, Tanzu Operations Manager uses 4789.

   • For Denied logging interval, enter the per-second rate limit for packets blocked by either a container-specific networking policy or by App Security Group (ASG) rules applied across the space, org, or deployment. The default value is 1. For more information, see Policies in container-to-container networking and Restricting app access to internal TAS for VMs Components.
   • For UDP logging interval, enter the per-second rate limit for UDP packets sent and received. The default value is 100.
   • To allow logging for app traffic, select the Log traffic for all accepted and denied app packets check box. Selecting this check box increases log volume. For more information, see App traffic logging in Configuring logging in TAS for VMs.

5. The Enforce Silk network policy check box is selected by default. To deactivate Silk network policy enforcement between apps, deselect this check box. Deactivating the network policy enforcement allows all apps to send network traffic to all other apps in your TAS for VMs deployment, despite no policy specifically allowing it.
   Deactivating the Enforce Silk network policy check box allows all app containers to access any other app container with no restrictions.

For DNS search domains, enter the domains for your app containers to use as DNS search domains as a comma-separated list. Your containers append these search domains to host names to resolve them into full domain names.

Database connection timeout

For Database connection timeout, enter in seconds the connection timeout for clients of the policy server and Silk databases. The default value is 120. You might need to increase this value if your deployment experiences timeout issues related to container-to-container networking.

Enable TCP routing

TCP routing is deactivated by default. You can enable this feature if your DNS sends TCP traffic through a load balancer rather than directly to a TCP router. To enable TCP routing:

1. Under TCP routing, select Enable.

   ImportantIf you have mutual TLS app identity verification enabled, app containers accept incoming communication only from the Gorouter. This deactivates TCP routing.

2. For TCP routing ports, enter one or more ports to which the load balancer forwards requests. To support multiple TCP routes, VMware recommends allocating multiple ports. Do one of these steps:
   • To allocate a single port or range of ports, enter a single port or a range of ports.

     NoteIf you configured AWS for Operations Manager manually, enter 1024-1123 which corresponds to the rules you created for pcf-tcp-elb.

   • To allocate a list of ports:
     1. Enter a single port in the TCP routing ports field.
     2. After deploying TAS for VMs, follow the procedure in Router Groups: Modify TCP port reservations.
3. (Optional) For TCP request timeout, modify the default value of 300 seconds. This field determines when the TCP router closes idle connections from clients to apps that use TCP routes. You might want to increase this value to enable developers to push apps that require long-running idle connections with clients.
4. Follow these additional instructions based on your IaaS:

   IaaS	Instructions
   GCP	Specify the name of a GCP TCP load balancer in the LOAD BALANCER field of the TCP Router job in the Resource Config pane. You configure this later on in TAS for VMs. For more information, see Configure Resources.
   AWS	Specify the name of a TCP ELB in the LOAD BALANCER field of the TCP Router job in the Resource Config pane. You configure this later on in TAS for VMs. For more information, see Configure Resources.
   Azure	Specify the name of a Azure load balancer in the LOAD BALANCER field of the TCP Router job in the Resource Config pane. You configure this later on in TAS for VMs. For more information, see Configure Resources.
   OpenStack and vSphere	Return to the top of the Networking pane. In the TCP router IPs field, ensure that you have entered IP addresses that are within your subnet CIDR block. These are the same IP addresses you configured your load balancer with in the Pre-Deployment Steps in Enabling TCP Routing, unless you configured DNS to resolve the TCP domain name directly to an IP you have chosen for the TCP router.

Additional settings:

• (Optional) For additional security, under HTTP response headers to remove, enter headers that you want the Gorouter to remove from app responses in the Header name field.
• (Optional) Under Sticky session cookies, enter one or more sticky session cookie names in the Cookie name field. The default cookie name is JSESSIONID. Some apps require a different cookie name. For example, Spring WebFlux requires SESSION for the cookie name. Gorouter uses these cookies to support session affinity, or sticky sessions. For more information, see Session Affinity in HTTP Routing.
• For Internal route staleness threshold, enter the amount of time, in seconds, that the Service Discovery Controller waits to receive messages about routes before pruning them from the routing table.

Remember to click Save.