While you are creating the DLB, you need to set some properties or you might want to pick some options as you see fit. Let’s have a closer look at those options.
Allowlisted CIDRs
You can set an allowlist that determines who/where can access your DLB. It is different from the VPC firewall rules. Even if you have only local access rules on your VPC, DLB still can be accessed according to its allowlist. It needs to be in CIDR notation. Default value is 0.0.0.0/0 .
Timeout in Seconds
This property sets the response timeout for the messages forwarded from DLB to the Mule applications that run inside the VPC. The default value is 300 seconds.
Inbound HTTP Mode
This option specifies the behavior of how DLB accepts an HTTP request. This property is particularly important because DLB is your entry point to your workers and you are setting how it behaves. So, from a security standpoint, it is important to understand this property. Let’s see what HTTP mode has to offer us with some examples.
There are 3 options;
HTTP Mode Off: Causes the load balancer to silently drop the HTTP request. That means your DLB endpoint will close its’ 80 port and will not accept any HTTP request. You can test the DNS like below, you will see that port 443 will connect but 80 will be refused.
>>> Telnet my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net 80
>>> Connecting To my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net…Could not open connection to the host, on port 80: Connect failed
HTTP Mode On: Accepts the inbound request on the default SSL endpoint using the HTTP protocol. So the endpoint will accept your request on both ports 80 and 443. You can connect to both ports with telnet.
HTTP Mode Redirect: Redirects the request to the same URL using the HTTPS protocol. That means it will accept your request over HTTP on an 80 port, but it will redirect your request to the HTTPS endpoint. As in Mode On, you can connect to both ports, you cannot observe any difference with telnet. But if you can use Postman to call this endpoint over HTTP with a GET, from the console you will see there are 2 requests instead of one. So our actual request is redirected with an HTTP Response Code 301 to our HTTPS endpoint. That is the second request and if you do not call an actual app behind the DLB, it will respond 403, because one does not simply call the DLB without a proper URI. You can observe the response from Diagram 5.
Static IP
Selecting this option seems obvious; it will assign your DLB workers static IPs. But don’t forget it is only Public IPs, as we mentioned before you cannot assign static private IPs. Mulesoft explained this limitation as due to their vendor (I guess they are pointing to AWS) capabilities. If you are using the DLB with 2 workers, then there will be 4 IPs assigned to your DLB due to HA configuration.
Keep URL Encoding
URL encoding converts characters into a format that can be transmitted over the Internet. URLs can only be sent over the Internet using the ASCII character set. Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format. URL encoding replaces unsafe ASCII characters with a “%” followed by two hexadecimal digits.
Keep URL encoding specifies that the DLB passes only the %20 (space) and %23 (#) characters as is. E.g. %20 is proxied as %20 to the backend without preliminary decoding.
If you leave this option deselected, the DLB decodes the encoded part of the request URI before passing it to the CloudHub worker. For further information on how you may handle special characters in the URLs, check the reference.
Support TLS 1.0
It is specified to support TLS 1.0 between the client and the DLB. To use TLS 1.0, see Enable TLS 1.0 on a DLB Using Runtime Manager.
Upstream TLS 1.2
It specifies to force TLS 1.2 between the DLB and the upstream CloudHub worker.
Forward Client Certificate
It specifies that the DLB forwards the client certificate to the CloudHub worker.
