anchor.diff:  
   ![vShield Edge Load Balancer Configure Service](/vcloud_images/load_bal_config_health_check.png)
   
  -Finally configure the members of the pool. There is only one member - the internal IP for the HA Proxy VM, assigned above:
  +Finally configure the members of the pool. There is only one member - the internal IP for the HAProxy VM, assigned above:
   
   ![vShield Edge Load Balancer Configure Service](/vcloud_images/load_bal_config_service.png)
   
  
positive.code: 
  ### Wildcard domains ###
  
  In general, we use a wildcard domain to map all apps and services running on a Cloud Foundry instance to its public IP address (i.e. the public IP address of HA Proxy in the deployment described in this documentation, or the IP address of a load balancer if that's being used). For example, if a Cloud Foundry instance uses the wildcard domain `*.mycf.com`, and the application `foo` is deployed to it, the URL `foo.mycf.com` can be used to access the foo application.
  
  The system services are made available in the same way - `api.mycf.com`, `console.mycf.com`, etc., may all be used. This can lead to some phishing opportunities, however. For example, someone could pretend to be a legitimate system service and create `change_your_password.mycf.com` or `sign_up_with_credit_card.mycf.com`. To avoid this, Cloud Foundry supports two domains, one for system applications and one for general applications. Only administrators of the system can deploy applications to the system domain.
  
  
negative.code: 
  In vCloud and vCloud Air deployments the various components of Cloud Foundry are installed on a private network, where each component does not have a publicly routable IP address. Instead, when internal VMs need to access public IP addresses we use source NAT (SNAT) to map these multiple internal addresses to a public address (just like your home WiFi router).
  
  Similarly, when an external machine tries to connect to Cloud Foundry, it will connect to a public IP address. This needs to then connect to the private IP address of the Cloud Foundry instance, specifically the HAProxy VM.
  
  The obvious solution to this is to use destination NAT (DNAT) to connect the Cloud Foundry public IP address to the HAProxy private address. However, we have found some issues with that approach. When the internal components of Cloud Foundry talk to each other over https (e.g. login server to the UAA) they use the wildcard domain described above to resolve host names to IPs. For example, when `login.mycf.com` wants to connect to `uaa.mycf.com` and does a DNS lookup, it will receive the public IP address of the Cloud Foundry instance. When it connects to this it should be SNATed to an external address and then DNATed to the HAProxy private IP address. We have found that, because of the way iptables rules are processed, this repeated NAT conversion from an internal IP to a public IP and back to internal does not happen correctly.
  
  We have found two ways to work around this:
  
  1. Use the vShield Edge Load Balancer to connect the Cloud Foundry public IP to the HAProxy private IP
  2. Use split-brain DNS, with an internal DNS server resolving the wildcard domain for internal VMs to the private IP of HAProxy
  
  The vShield Edge Load Balancer is the simpler of the two to set up and so the following sections detail the steps used to set up the network environment using that approach.
  
  