Skip to content

NCD – Network Connectivity Troubleshooting

← NCD – Networking

Diagnosing network connectivity problems as detailed in this article relies on use of the Ping command. Ping is a network administration software utility used to test connectivity on an Internet Protocol (IP) network. Refer to Executing Ping Commands for details on use of the Ping command.

Network Connectivity Problems

Below is a list of possible network connectivity problems, providing links to detailed instructions for diagnosing and correcting them.

Unable to Ping Between Two VMs on the Same vDC/vApp Network Within the Same DataCenter


Assumption: Your network configuration is similar to one of those illustrated below, and you are unable to ping between the X.2 and X.4 VMs as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct, and…
  • your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow the expected network traffic.

  • you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Ping a Network Gateway Device from a VM Within the Network


Assumption: Your network configuration is similar to one of those illustrated below, and you are unable to ping the network gateway for the x.2 VM (either a vApp gateway or an Edge Gateway) as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct…
  • verify that the VM has connectivity to its network gateway device by pinging the ‘.1’ address of the network (typically a 10.x.x.1 or 192.168.x.1 address).
If your VM is unable to ping the network gateway device…
  • verify that the vApp network has the correct Firewall rules configured to allow you to ping the network gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Ping an Internet Address from a Navisite Cloud Director VM


Assumption: Your network configuration is similar to one of those illustrated below, and you are unable to ping between the VM and an internet address as illustrated.



Start: If the VM in question is connected to a vApp network, verify that the vApp network and higher-level vDC network are NOT using the same network space.
  • Remember that a vApp network and the vDC network it connects to are by definition two separate networks with two individual gateway devices.
If the vApp network and the vDC network have matching addresses:

You must change the address space of one network (either the vApp network or the vDC network) and reconfigure firewall and NAT rules for the VM to access the internet.

To do this, you have two options:
  • Conversely, you can create a new VM network inside the existing vApp with a different network address space, and reconnect the VMs in question to this new vApp network. For more detailed guidance, consult documents on creating a VM network and editing VM properties. 
Next: Verify the VM network settings. To do so:
  • Verify VM IP settings and ensure that your VM network settings are as expected.

    Note that in order to configure the NAT rules required to get from a vApp network (e.g., 192.168.x.0/24) to a vDC network (e.g., 10.x.x.0/24), as illustrated in the rightmost diagram above, your VM must be configured to use static IP addresses (either from a static IP pool, or by manual IP assignment).
If your VM network settings are incorrect, and…
If your VM network settings are correct, and it is behind a vApp gateway…
  • verify that the VM has connectivity to its vApp network gateway device by pinging the ‘.1’ address of the vApp network (typically a 192.168.x.1 address).
If your VM is unable to ping the vApp gateway device…
  • verify that the vApp network has the correct Firewall rules configured to allow you to ping the vApp gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your VM network settings are correct and it is able to ping the vApp gateway device, or it is not behind a vApp gateway…
  • verify that the VM has connectivity to its internet Edge Gateway by pinging the ‘.1’ address of the vDC network (typically a 10.x.x.1 address).
If your VM is unable to ping the Edge Gateway device…
  • verify that the vDC network has the correct Firewall rules configured to allow you to ping the Edge Gateway device. Review Pinging Your Network Gateway in order to verify that the vDC network is correctly configured to allow Ping (ICMP) network traffic.

  • verify that your vApp network has a NAT rule configured to allocate a vDC network IP address to the VM. Review Connecting a vApp-Networked VM to Your vDC Network to verify that the correct NAT rule has been configured.

  • if you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your VM network settings are correct and it is able to ping the Edge Gateway device…
  • verify that the VM has connectivity to the internet by attempting to ping IP address 8.8.8.8
If your VM is unable to ping an internet address…
  • verify that the vDC network has a default SNAT rule, and that it has been correctly configured. Review Configuring a Default SNAT Rule to ensure that your vDC network has a correct SNAT rule in place to allow internet-bound traffic to pass.

  • if you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.

Unable to Ping Between VMs Within the Same DataCenter on Different vDC Networks


Assumption: Your network configuration is similar to the following illustration, and you are unable to ping between the X.2 and Y.4 VMs as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct…
  • verify that each VM has connectivity to its Edge Gateway device by pinging the ‘.1’ address of the network (typically a 10.x.x.1 address).
If your VM is unable to ping its Edge Gateway device…
  • verify that the vDC network has the correct Firewall rules configured to allow you to ping the Edge Gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your VM network settings are correct and it is able to ping its Edge Gateway device…
  • verify that the VM has connectivity to the other vDC network by attempting to ping its Edge Gateway device.
If your VM is unable to ping the Edge Gateway device on the other vDC network…
  • if you are uncertain of the other vDC network's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy that Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Ping Between VMs in Different DataCenters


Assumption: Your network configuration is similar to the following illustration, and you are unable to ping between the X.2 and Y.4 VMs as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct…
  • verify that each VM has connectivity to its Edge Gateway device by pinging the ‘.1’ address of the network (typically a 10.x.x.1 address).
If your VM is unable to ping its Edge Gateway device…
  • verify that the vDC network has the correct Firewall rules configured to allow you to ping the Edge Gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your VM network settings are correct and it is able to ping its Edge Gateway device…
  • verify that the VM has connectivity to the vDC network at the other datacenter by attempting to ping across datacenter networks to its Edge Gateway device.
If your VM is unable to ping the Edge Gateway device on the vDC network at the other datacenter…
  • verify the presence of a functioning VPN connection between the datacenters. See Connecting Data Centers Using a Virtual Private Network (VPN) to verify the VPN connection.

  • if you are uncertain of the status of the vDC network Edge Gateway at the other datacenter, review Redeploying an Edge Gateway in order to redeploy that Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Ping a Dual-NIC VM in Navisite Cloud Director From a VPN-Connected Network


Assumption: Your network configuration is similar to the following illustration, and you are unable to ping PC1 (10.Y.Y.104) from PC2 (10.Z.Z.100) as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct…
  • verify that each VM has connectivity to its Edge Gateway device by pinging the ‘.1’ address of the network (typically a 10.x.x.1 address).
If your VM is unable to ping its Edge Gateway device…
  • verify that the vDC network has the correct Firewall rules configured to allow you to ping the Edge Gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if you are uncertain of your environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your VM network settings are correct and it is able to ping its Edge Gateway device…
  • verify that the VM has connectivity to the vDC network at the other datacenter by attempting to ping across datacenter networks to its Edge Gateway device.
If your VM is unable to ping the Edge Gateway device on the vDC network at the other datacenter…
  • verify the presence of a functioning VPN connection between the datacenters. See Connecting Data Centers Using a Virtual Private Network (VPN) to verify the VPN connection.

  • verify that the dual-NIC VM is correctly configured to route network traffic arriving from the remote VPN subnet. See Dual NIC VMs and Asymmetrical Routing for details on identifying and avoiding asymmetrical routing problems.

  • if you are uncertain of the status of the vDC network Edge Gateway at the other datacenter, review Redeploying an Edge Gateway in order to redeploy that Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Ping Between a VM in a Navisite Cloud Director DataCenter and a VM in a Customer Site DataCenter


Assumption: Your network configuration is similar to the following illustration, and you are unable to ping between PC1 (10.Y.Y.104) and PC2 (10.Z.Z.100) as illustrated.



Start: Verify the network settings of each VM. To do so:
If your VM network settings are incorrect, and…
If your VM network settings are correct…
  • verify that the VM in the Navisite Cloud Director datacenter has connectivity to its Edge Gateway device by pinging the ‘.1’ address of the network (typically a 10.x.x.1 address).
If the VM in the Navisite Cloud Director datacenter is unable to ping its Edge Gateway device…
  • verify that the vDC network has the correct Firewall rules configured to allow you to ping the Edge Gateway device. Review Pinging Your Network Gateway in order to verify that the network is correctly configured to allow Ping (ICMP) network traffic.

  • if your VM is running a Microsoft Windows operating system, verify your Windows firewall settings as detailed in Windows Firewall Settings to ensure that your Windows VM firewall is configured to allow ICMP (ping) network traffic.

  • if you are uncertain of your Navisite Cloud Director environment's Edge Gateway status, review Redeploying an Edge Gateway in order to redeploy the environment's Edge Gateway and eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
If your Navisite Cloud Director VM network settings are correct and it is able to ping its Edge Gateway device…
  • verify that the VM has connectivity to the customer site datacenter network by attempting to ping across datacenter networks to its gateway device.
If your Navisite Cloud Director VM is unable to ping the gateway device on the customer site datacenter network…
  • verify that the customer site datacenter network has the correct firewall rules configured to allow Ping (ICMP) network traffic to its gateway device.

  • verify the presence of a functioning VPN connection between the datacenters. See Third Party VPN Connections to verify the VPN connection.

  • if you are uncertain of the status of the customer site datacenter gateway device, consider an appropriate redeploy or reset operation to eliminate it as the possible source of network failure.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Unable to Access a Navisite Cloud Director Windows VM from an External Network Location using Remote Desktop Protocol (RDP)


Assumptions:
  • Your network configuration is similar to one of those illustrated below.

  • You are attempting to connect to the Navisite Cloud Director VM via RDP using a public IP address that is associated with the VM with the use of a NAT rule.

  • The VM to which you are attempting to connect is a stand-alone virtual machine that has never been part of a domain group.



Start: Verify network connectivity between the VM and the machine at the external network location as detailed in Unable to Ping an Internet Address from a Navisite Cloud Director VM.

If you are able to ping between the VM and the machine at the external network location, but are unable to establish an RDP connection between them…
  • see Remote Desktop Protocol (RDP) Network Rules to determine whether the correct networking rules are in place to allow RDP access to your Navisite Cloud Director environment.

  • see Enabling Remote Desktop (RDP) Support to determine whether the Windows VM's operating system is configured to allow Remote Desktop connections.

  • review Windows Firewall Settings to determine whether your Windows VM firewall settings are configured to allow RDP network traffic.

  • if all troubleshooting efforts fail, see Contacting Support for details on how to engage the support team to diagnose any potential network infrastructure issues.
Back to top

Support Reference Material

Executing Ping Commands

Diagnosing network connectivity problems as detailed in this article relies on use of the Ping command. Ping is a network administration software utility used to test connectivity on an Internet Protocol (IP) network. It also measures the latency or delay between two devices.

To test network connectivity with Ping:
  1. Open the Command Prompt or Terminal (if pinging between VMs, open the Command Prompt or Terminal on one of the VMs). Every operating system has a command line interface that will allow you to run the Ping command. The Ping command operates identically on all systems.

    • If using Windows, open the Command Prompt. Click the Windows Start button and enter "cmd" into the Search field. Windows 8 users can type "cmd" while on the Start screen. Press Enter to launch the Command Prompt.

    • If using Mac OS X, open your Applications folder, and then open the Utilities folder, and select Terminal.

    • If using Linux, Open a Telnet/Terminal window. It is most often found in the Accessories folder in your Applications directory.

  2. Type ping followed by an IP address or a host name, and then press Enter key to execute the command (examples: ping 192.168.1.1, ping google.com)
Successful Ping commands return several "Reply from" messages with the responding IP address, indicating that the device is online and has internet access. Successful Ping commands also return statistics indicating any packet loss (which might result from an unstable connection) and the average time that the device took to answer the command.

Unsuccessful Ping Command Replies

The following replies may be received due to an unsuccessful Ping command:

Request Timed Out
This message indicates that no reply was received within the default time of 1 second. Most often, it means that a route back to the sending host has failed Other causes include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.

Unknown Host
This error message indicates that the requested host name cannot be resolved to its IP address; check that the host name is entered correctly and that the DNS servers can resolve it.

Destination Host Unreachable
This message indicates one of two problems. Either…
  • the local system has no route to the desired destination (message: "Destination Host Unreachable"). Use the Route utility to check the local routing table.

    • or

  • a remote router reports that it has no route to the destination (message: "Reply From [IP address]: Destination Host Unreachable" – the remote router's address is indicated by the [IP address] value). Check the IP routing table of the router. If the Ping command was issued using an IP address, retry it with a host name to ensure that the IP address you tried is correct.
Back to top

Verifying VM IP Settings

In order for a VM to have network access, its network configuration must be correct, including VM IP addresses, subnet masks, and default gateway settings.

Ubuntu/RedHat/CentOS

For a Ubuntu/RedHat/CentOS VM, the VM IP address and subnet mask can be verified by issuing the ifconfig command within a terminal window. Default network gateway settings can be verified by issuing the route command.





Windows

For a Microsoft Windows VM, the IP address, subnet mask, and gateway settings can be verified by issuing the ipconfig command from a Command Prompt window.



Back to top

Updating VM Network Interface Settings

Information on how to adjust the network settings of a VM in Navisite Cloud Director can be found in Editing VM Properties in the "Managing VM Network Interfaces" section.

After changing your VM network settings, remember that you will need to fully power off and then repower your VM in order for the changes to take effect. See Recustomizing a VM for more information on how to correctly reconfigure your VM.

Back to top

Determining Why a VM Does Not Have an IP Address

Several reasons why your VM might not be able to obtain an IP address are detailed below, along with information on correcting them.

Dynamic IP Allocation (DHCP)

A VM on a network using Dynamic Host Configuration Protocol (DHCP) might experience a failure to obtain an IP address from the DHCP server. If you believe that your VM should be configured to use DHCP to obtain an IP address, perform the following tasks to try to isolate the problem.

Verifying that the VM is Configured for DHCP
From within Navisite Cloud Director, navigate to the network page for the network to which the VM is connected, as follows:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the VM. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click Networks.

  6. In the "Networks" list, click the name of the network to which the VM is connected. The Network page appears.

  7. At the Network page, scroll down to the "IP Allocation" section and click IP Addressing.

  8. In the "IP Addressing" section, verify that the "DHCP Enabled:" field is set to Yes.
Instructions for enabling DHCP in Navisite Cloud Director can be found in How do I edit vDC network properties?

Verifying that Enough DHCP Addresses are Configured for Your Environment
From within Navisite Cloud Director, navigate to the network page for the network to which the VM is connected, as detailed in Steps 1-7 above.

Note the displayed DHCP IP range in the "IP Addressing" section. Verify that the DHCP range is large enough to accommodate the number of VMs in your environment that are configured to use DHCP.

Instructions for adjusting DHCP settings in Navisite Cloud Director can be found in How do I edit vDC network properties?

VMware Tools Status

An outdated version of VMware Tools installed on a VM can cause it to be unable to obtain an IP address. The following steps detail how to determine whether VMware Tools are up to date for the VM, and how to update them if they are not.
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the desired VM. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click VMs.

  6. Locate and click the desired VM name in the list. The VM detail page appears.

  7. Verify that the VM is powered on. If necessary, click the green Power On (Play) button at the top of the VM detail page.

  8. Scroll down to the "Configuration" section and click VM Config to display the VM configuration settings.

  9. Verify that the listed "VMware Tools:" version is accompanied by a green checkmark, indicating that the latest version of VMware Tools is installed.

  10. If the latest version of VMware Tools is not installed, click Install version… to update the VM to the latest version of VMware Tools. After updating, repeat this procedure to verify that the latest version of VMware Tools is in use.
Note: Updating VMware Tools normally requires a VM to be rebooted. It is recommended that such updates be performed during scheduled maintenance windows, and that a backup of the VM is created.

Back to top

Recustomizing a VM

If you have recently changed your VM's network settings (from a statically assigned IP to DHCP assignment, for example), the VM must be shut down, powered down, and then restarted in order for the VM to be correctly recustomized, regardless of the VM's operating system.

Properly shut down/power down/restart your VM in order to update the VM's network settings as follows:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the desired VM. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click VMs.

  6. Locate and click the desired VM name in the list. The VM detail page appears.

  7. Shut down the VM by selecting "Shutdown" from the red Power Off (Stop) drop-down menu at the top of the VM detail page.

  8. Power off the VM by clicking the red Power Off (Stop) button at the top of the VM detail page.

  9. Restart the VM by clicking the green Power On (Play) button at the top of the VM detail page.
Back to top

Redeploying an Edge Gateway

It is recommended that the redeployment of an Edge Gateway device occur during a scheduled maintenance window. While it is a low-impact operation resulting in a very brief loss of network connectivity, you may experience a small amount of packet loss while redeploying an Edge Gateway, and any connected VPN tunnels will collapse, so it should be avoided when operations such as non-recoverable file transfers are being performed.

The redeployment of an Edge Gateway results in the loss of log files on the Edge Gateway. You may wish to consider contacting Navisite Cloud Director Support in order to download log files prior to redeployment. See Contacting Support for information on engaging the Support team.

For specific instructions on redeploying an Edge Gateway in Navisite Cloud Director, see Redeploying an Edge Gateway.

Back to top

Contacting Support

For instructions on contacting Navisite Cloud Director Support, see Contacting Support.

When contacting Support, please provide as much detail as possible relating to the issue being experienced, including information on all NaviSite-provided troubleshooting procedures attempted prior to contacting Support.

Back to top

Pinging Your Network Gateway

In order to ping your network gateway, you must first configure the gateway device to allow ICMP traffic. To do so:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. In the "vDataCenters" list, click the name of the desired vDataCenter. The vDataCenter detail page appears.

  3. At the vDataCenter detail page:

    To configure the vDC network's Edge Gateway:

    1. Scroll down to the "Network Services" section and click Firewall.

    To configure a vApp network gateway device:

    1. Scroll down to the "Children" section and click vApps.

    2. In the "vApps" list, click the name of the desired vApp. The vApp detail page appears.

    3. Scroll down to the "Children" section and click Networks.

    4. In the "Networks" list, click the name of the desired vApp network. The vApp Network page appears.

    5. Click Firewall in the "Services" section of the vApp Network page. The "Firewall" section displays the current status of any existing firewall rules defined for the vApp network.

  4. Click the "gear" icon in the upper right corner of the "Firewall" section to display the Firewall page.

  5. At the Firewall page, click +Add Rule. The Add Firewall Rule page appears.

  6. At the Add Firewall Rule page, create a firewall rule to allow ICMP (ping) traffic as detailed in Configuring Firewall Rules.

    Create the rule using the following settings:

    • Name: EnablePing
    • Protocol: ICMP
    • Action: Allow
    • Source: Any
    • Source Port: Any
    • Destination: Any
    • Destination Port: Any

  7. Click Add Firewall Rule to add the new rule and return to the Firewall page.

  8. At the Firewall page, click Save.

  9. Allow Navisite Cloud Director to complete the creation of the firewall rule before proceeding.
Note: You can monitor the progress of the vApp creation by clicking the Recent Tasks icon in the upper right corner of the page.

Once the firewall rule is created, you should be able to ping the network gateway. The gateway is usually the .1 address on the network of interest, typically a 192.168.x.1 address for a vApp network, or a 10.x.x.1 address for a vDC network.

Disabling Your Network Gateway Firewall

You can determine whether your network gateway firewall settings are preventing ICMP(ping) traffic by temporarily disabling your network gateway firewall.

Note: Disabling your network gateway firewall will leave your network unprotected from network-related security threats, so it is recommended that the firewall be disabled for as little time as possible during network connectivity testing.

To disable your network gateway firewall:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. In the "vDataCenters" list, click the name of the desired vDataCenter. The vDataCenter detail page appears.

  3. At the vDataCenter detail page:

    To disable the vDC network's Edge Gateway:

    1. Scroll down to the "Network Services" section and click Firewall.

    To disable a vApp network gateway device:

    1. Scroll down to the "Children" section and click vApps.

    2. In the "vApps" list, click the name of the desired vApp. The vApp detail page appears.

    3. Scroll down to the "Children" section and click Networks.

    4. In the "Networks" list, click the name of the desired vApp network. The vApp Network page appears.

    5. Click Firewall in the "Services" section of the vApp Network page. The "Firewall" section displays the current status of any existing firewall rules defined for the vApp network.

  4. Click the "gear" icon in the upper right corner of the "Firewall" section to display the Firewall page.

  5. Deselect the Enabled checkbox at the top of the Firewall page.

  6. Click Save at the bottom of the Firewall page.
When your testing is complete, enable the firewall by repeating Steps 1-4 above and selecting the Enabled checkbox at the top of the Firewall page. Click Save to enable the firewall.

Back to top

Connecting a vApp-Networked VM to Your vDC Network

VMs residing within a vApp network must be connected to a vDC network in order to have internet access. This connection is established using a Network Address Translation (NAT) rule, which is created in Navisite Cloud Director by default when a vApp and VM are created within a vDC. If this NAT rule is removed, however, the VM will lose internet access.

In order to restore internet access to the VM, an IP address on the vDC network must be assigned to the VM, and a NAT rule must be created to map that IP address to its vApp network IP address. To do so:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the desired VM. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click Networks.

  6. In the "Networks" list, click the name of the vApp network to which the VM is connected. The vApp Network page appears.

  7. Click NAT in the "Services" section of the vApp Network page. The "NAT" section displays the current status of any existing NAT rules defined for the vApp network.

  8. Click the "gear" icon in the upper right corner of the "NAT" section to display the NAT page.

  9. At the NAT page, create the NAT rule to map your vApp VM IP address to a vDC IP address as detailed in Configuring NAT Rules.

    Create the NAT rule using the following settings:

    • Mapping Mode: Automatic
    • VM Interface: Select the appropriate VM from the drop-down menu

    Note: Only VMs with static IPs are provided in the "VM Interface" drop-down menu. If the VM uses DHCP to obtain an IP address, it will need to be reconfigured with a statically assigned IP address. See Updating VM Network Interface Settings for information on updating VM network settings.

  10. Click Add NAT Rule to add the rule and return to the NAT page.

  11. At the NAT page, click Save to save the NAT rule.
Back to top

Configuring a Default SNAT Rule

When a vDC is created within Navisite Cloud Director, a new Edge Gateway device is created containing a set of default network access control lists (ACLs), which allow outside connectivity from within the Navisite Cloud Director environment.

To allow this connectivity, a default SNAT rule is created that translates IP addresses from the environment's vDC network to the public IP interface. If the default SNAT rule is removed or altered, it can result in the loss of outside network connectivity from within the vDC network.

In order to restore connectivity, you can recreate or correct the default SNAT rule by editing the Edge Gateway NAT settings as follows:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. Click NAT in the "Network Services" section of the vDataCenter detail page. The "NAT" section displays the current status of any existing NAT rules defined for the vDC network.

  4. Click the "gear" icon in the upper right corner of the "NAT" section to display the NAT page.

  5. At the NAT page, create or correct the SNAT rule as detailed in Configuring NAT Rules.

    Create or edit the SNAT rule using the following settings:

    • Enable: Select the "Enabled" checkbox
    • Type: Source
    • Applied On: Select "internet 01" for the appropriate data center environment
    • Original IP: Select the vDC network requiring translation from the "Original IP Suggestions…" drop-down menu
    • Translated IP: Select the public IP of the vDC network from the "Translated IP Suggestions…" drop-down menu

  6. Click Add/Update NAT Rule to add or edit the rule and return to the NAT page.

  7. At the NAT page, click Save to save the NAT rule.
Back to top

Connecting Data Centers Using a Virtual Private Network (VPN)

In order to establish a secure network connection between two virtual data centers in Navisite Cloud Director, a VPN connection must be configured.

Details on configuring this connection in Navisite Cloud Director can be found in Configuring VPNs Between vDataCenters.

Note: When reviewing site-to-site VPN status in Navisite Cloud Director, note that the displayed operational status may not accurately reflect the actual status of the VPN connection. This is a known network infrastructure issue that is currently being investigated by VMware. Until this issue is resolved, it is recommended that VPN connectivity be validated by using a continuous ping between VPN sites instead of relying on the displayed operational status.

Back to top

Dual NIC VMs and Asymmetrical Routing

Asymmetrical routing occurs when network traffic travels from a source network to a destination network using one network path, but attempts to return back to the source network using a different network path. VMs configured with multiple network interface controllers (NICs) on separate networks can experience asymmetrical routing. Due to security concerns, firewalls and/or NAT devices will typically drop network traffic that shows inconsistent source and destination state information.

Diagnosing Asymmetrical Routing

Asymmetrical routing is the result of a VM receiving data from an unknown network source (e.g., a network to which the VM is not directly connected) on one NIC adapter and then using a default route to send data back to the unknown source network on a different NIC.

To effectively identify an asymmetrical routing configuration:
  • Review your VM's network configuration and note its default gateway settings (see Verifying VM IP Settings).

  • Examine your environment's network architecture and note the network on which unknown network traffic is expected to arrive.
If the network that hosts your default gateway is different than the network on which unknown network traffic is expected to arrive, you may experience asymmetrical routing issues.

Example: A VM is directly connected to two networks – 10.10.10.0/24 and 10.11.11.0/24 – and it is configured to use 10.10.10.1 as its default network gateway. Network architecture dictates that network traffic is expected from a 192.168.1.0/24 network to the 10.11.11.0/24 network using a VPN connection. Because the default gateway network (10.10.10.0/24) is different from the network on which unknown network traffic is expected to arrive (10.11.11.0/24), asymmetrical routing issues should be expected.

Correcting Asymmetrical Routing Problems

If you determine that your VM is asymmetrically routing data, you can correct the issue by updating your VMs routing configuration to ensure that data received from any outside networks is sent to the correct network interface. To do so:

Ubuntu/RedHat/CentOS
For a Ubuntu/RedHat/CentOS VM, you can add a network route via a terminal command line by issuing the following command (included IP addresses are for example purposes only):

route add –net 10.10.9.0 netmask 255.255.255.0 gw 10.10.8.1 dev eth1
  • net should be set to the IP address of the remote network to which data should be routed

  • netmask should be set to the netmask of the remote network to which data should be routed

  • gw should be set to the IP address of the network gateway through which data intended for the remote network specified by net should be routed

  • dev should specify the network adapter device hosting the network on which gw can be accessed
Route updates made via the command line remain in place until the VM is rebooted or the VM network is reset. In order to make your updates persistent, the VM configuration must be edited.

Ubuntu
For a Ubuntu VM, you can add a network route by editing /etc/network/interfaces to add the following command (included IP addresses are for example purposes only):

post-up route add –net 10.10.9.0 netmask 255.255.255.0 gw 10.10.8.1 dev eth1
  • net should be set to the IP address of the remote network to which data should be routed

  • netmask should be set to the netmask of the remote network to which data should be routed

  • gw should be set to the IP address of the network gateway through which data intended for the remote network specified by net should be routed

  • dev should specify the network adapter device hosting the network on which gw can be accessed
RedHat/CentOS
For a RedHat/CentOS VM, you can add a network route by editing /etc/sysconfig/network-scripts/route-eth1 to add the following command (included IP addresses are for example purposes only):

10.10.9.0/24 via 10.10.8.1 dev eth1
  • the initial IP address and CIDR notation (example: 10.10.9.0/24, above) should be set to the IP address and CIDR notation of the remote network to which data should be routed

  • via should be set to the IP address of the network gateway through which data intended for the remote network specified above should be routed

  • dev should specify the network adapter device hosting the network on which the gateway specified by via can be accessed

Windows
For a Windows VM, you can add a network route via a cmd terminal by issuing the following command (included IP addresses are for example purposes only):

route add 10.10.9.0 mask 255.255.255.0 10.10.8.1 metric 6
  • add should be set to the IP address of the remote network to which data should be routed

  • mask should be set to the netmask of the remote network to which data should be routed

  • the network gateway address value (immediately following the mask value) should be set to the IP address of the network gateway through which data intended for the remote network specified by add should be routed
Route updates for a Windows VM performed using the route add command remain in place until the VM is rebooted. To make route updates persistent, add –p to the route add command, as shown in the following example:

route add 10.10.9.0 mask 255.255.255.0 10.10.8.1 metric 6 -p

Back to top

Third Party VPN Connections

Determining Whether a VPN Connection Exists

Network connectivity problems can be caused by a non-operational third party (i.e., customer site-to-Navisite Cloud Director) VPN connection. You should first confirm that such a VPN connection has been configured. Information on how to view a third party VPN connection in Navisite Cloud Director can be found in Configuring VPNs Between On-Premise Networks and vDataCenters.

Troubleshooting a Third Party VPN Connection

Information on how to troubleshoot a non-operational third party VPN connection can be found in Troubleshooting Third-Party VPN Connections.

Note: When reviewing third party VPN status in Navisite Cloud Director, note that the displayed operational status may not accurately reflect the actual status of the VPN connection. This is a known network infrastructure issue that is currently being investigated by VMware. Until this issue is resolved, it is recommended that VPN connectivity be validated by using a continuous ping between VPN sites instead of relying on the displayed operational status.


Back to top

Windows Firewall Settings

When troubleshooting VM network connectivity issues, note that the Windows operating system (beginning with Windows XP and Windows 2003) provides its own firewall and packet filtering software. The firewall settings on Windows VMs should be reviewed to verify that the filtering rules being enforced are not causing expected network traffic to be rejected.

Note: This section provides Windows Firewall details specific to Windows 2008 and 2012, which are the Windows versions currently provided as public Navisite Cloud Director Windows VM templates.

Accessing Windows Firewall

The firewall settings on a Windows VM can be accessed as follows:
  1. Log into the desired Windows VM.

  2. Click the Windows Start button, and select Control Panel from the resulting menu.

  3. Enter firewall in the Search field, and click Windows Firewall. The Windows Firewall Control Panel window appears.

Enabling/Disabling Windows Firewall

To enable or disable the Windows Firewall:
  1. From within the Windows Firewall Control Panel, click Turn Windows Firewall on or off in the pane at the left side of the window. The Customize Settings dialog window appears.

  2. Within the Customize Settings window, enable Windows Firewall for each network type for which firewall protection is desired.

    Note: At a minimum, Windows Firewall should be enabled for Public Networks.

  3. Click OK.
Note: You can determine whether your Windows Firewall settings are preventing ICMP(ping) and/or RDP traffic by temporarily disabling your Windows firewall. Note that disabling the Windows Firewall will leave your Windows VM unprotected from network-related security threats, so it is recommended that the firewall be disabled for as little time as possible during network connectivity testing.

Enabling ICMP (Ping) Network Traffic
To enable ping traffic to and from your Windows VM:
  1. In the Windows Firewall Control Panel, click Advanced settings in the pane at the left side of the window. The Windows Firewall with Advanced Security window appears.

  2. Select Inbound Rules in the pane at the left side of the window.

  3. Double-click File and Printer Sharing (Echo Request – ICMPv4-In). The File and Printer Sharing (Echo Request – ICMPv4-In) Properties window appears with the "General" tab displayed.

  4. Select the Enabled checkbox and verify that the Allow the connection radio button is selected.

  5. Click Apply.

  6. Click OK to return to the Windows Firewall with Advanced Security window.

  7. Select Outbound Rules in the pane at the left side of the window.

  8. Double-click File and Printer Sharing (Echo Request – ICMPv4-Out). The File and Printer Sharing (Echo Request – ICMPv4-Out) Properties window appears with the "General" tab displayed.

  9. Select the Enabled checkbox and verify that the Allow the connection radio button is selected.

  10. Click Apply.

  11. Click OK to return to the Windows Firewall with Advanced Security window, and close it.

Enabling Remote Desktop Protocol (RDP) Network Traffic
To enable RDP traffic to your Windows VM:
  1. In the Windows Firewall Control Panel, click Advanced settings in the pane at the left side of the window. The Windows Firewall with Advanced Security window appears.

  2. In the "Overview" section, select Windows Firewall Properties. The Windows Firewall with Advanced Security window appears.

  3. Using the "Domain Profile," "Private Profile," and "Public Profile" tabs, configure the following firewall rule application policies:

    • Firewall State – set to On or Off

      • at a minimum you should set the firewall state on the "Public Profile" tab to On

    • Inbound Connections – define whether incoming connections are allowed, blocked or all blocked

      • Allowed – allows all incoming connections

      • Block all connections – blocks all incoming connections regardless of defined inbound rules

      • Block – block all incoming connections that do not match a defined inbound rule

        • at a minimum you should set Inbound Connections on the "Public Profile" tab to Block

    • Outbound Connections – define whether outbound connections are allowed, blocked or all blocked

      • Allowed – allows all outbound connections

      • Block all connections – blocks all outbound connections regardless of defined outbound rules

      • Block – block all outbound connections that do not match a defined outbound rule

        • at a minimum you should set Outbound Connections on the "Public Profile" tab to Allowed

  4. Click OK to return to the Windows Firewall with Advanced Security window.

  5. Select Inbound Rules in the pane at the left side of the window.

  6. Double-click Remote Desktop – User Mode (TCP-In). The Remote Desktop – User Mode (TCP-In) Properties window appears with the "General" tab displayed.

  7. Select the Enabled checkbox and verify that the Allow the connection radio button is selected.

  8. Select the "Advanced" tab.

  9. In the Profiles section, select the profile to which you would like RDP access rules applied.

    • at a minimum you should select the Public profile

  10. Click Apply.

  11. Click OK to return to the Windows Firewall with Advanced Security window.

Back to top

Remote Desktop Protocol (RDP) Network Rules

Verify that your Navisite Cloud Director network is correctly configured to allow RDP traffic as detailed below.

Verifying vDataCenter (vDC) Edge Gateway Network Settings

  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. Scroll down to the "Network Services" section and click Firewall.

  4. Verify that a firewall rule is configured allowing RDP (port 3389) traffic into your Navisite Cloud Director environment from a public IP address.



  5. Click NAT in the "Network Services" section of the vDataCenter detail page.

  6. Verify that a destination NAT (DNAT) rule is configured mapping RDP traffic from your environment's public IP to the IP address of a VM within your Navisite Cloud Director environment.


Verifying vApp Gateway Network Settings

If your VM resides on a vApp network within a vDC network, you should also verify that the vApp network's settings are configured to allow RDP traffic, as follows:
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the VM to which you wish to establish an RDP connection. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click Networks.

  6. In the "Networks" list, click the name of the vApp network to which the desired VM is connected. The Network page appears.

  7. At the Network page, scroll down to the "Services" section and click Firewall.

  8. Verify that a firewall rule is configured allowing RDP (port 3389) traffic into the vApp network.



  9. Click NAT in the "Services" section of the Network page.

  10. Verify that a NAT rule is configured mapping traffic from the vDC network to the VM on the vApp network.


Adding or Repairing RDP Public Service Behavior

If the necessary networking rules to allow RDP access to your Navisite Cloud Director environment are not in place, you can configure them by adding or repairing the VM's RDP public service behavior as follows:

Note: A virtual machine (VM) must be in a powered on state in order to successfully configure network behaviors for it, or a configuration error occurs. If necessary, click the Power On (Start) button at the top of the VM detail page to power on the VM before configuring network behaviors.

Accessing Behaviors
  1. At the Navisite Cloud Director Dashboard page, click vDataCenters in the navigation bar on the left side of the page to display the vDataCenters page.

  2. Click the desired vDC name in the list. The vDataCenter detail page appears.

  3. At the vDataCenter detail page, scroll down to the "Children" section and click vApps.

  4. In the "vApps" list, click the name of the vApp containing the VM to be configured. The vApp detail page appears.

  5. At the vApp detail page, scroll down to the "Children" section and click VMs.

  6. In the "VMs" list, click the name of the VM to be configured. The VM detail page appears.

  7. At the VM detail page, scroll down to the "Configuration" section and click Behaviors. The "Behaviors" list displays any behaviors currently configured for the VM.
Repairing Behaviors
If an RDP public service behavior (using port 3389) exists for the VM, the details of any error conditions associated with it are displayed in the "Information" column of the "Behaviors" list, accompanied by a red X.

While Navisite Cloud Director attempts to automatically correct error conditions, certain errors (missing RDP network rules, for example) require you to click the Repair button in the "Behaviors" list in order to correct them, as illustrated below.


When elements of the behavior are successfully configured, they are displayed in the "Information" column with a green check mark. When an entire behavior is successfully configured, a green check mark appears in the "Status" column for the behavior.

Adding RDP Public Service Behavior
To add or modify a Public Service behavior for a VM:
  1. To add a new RDP Public Service behavior, click +Add Behavior above the "Behaviors" list. The Behaviors page appears.



  2. Click +Add Behavior in the "Public Service" section of the Behaviors page. The Public Service page appears.





  3. From the "VM NIC" drop-down menu, select VM Network: NIC 0.

  4. In the "Public IP" field, enter or select the public IP address to be used in order to gain RDP access to the VM.

  5. Select TCP from the "Protocol" drop-down menu.

  6. Select RDP (port 3389) from the "Port" drop-down menu.

  7. Click Add Behavior to configure the behavior. When the new behavior is successfully created, it is added to the "Behaviors" list at the VM detail page.

    8. Note: You can monitor the progress of the behavior creation by clicking the Recent Tasks icon in the upper right corner of the page.



Back to top

Enabling Remote Desktop (RDP) Support

In addition to allowing restrictions to Remote Desktop (RDP) traffic using the Windows Firewall, the Windows operating system also allows you to reject remote desktop connections using operating system (OS) configuration settings. In order to connect using RDP, the Windows OS must be configured to allow Remote Desktop connections, as follows.

Windows Server 2012

  1. From the Windows desktop, navigate to Settings. The System window appears.

  2. Within the System window, click Advanced System Settings. The System Properties window appears.

  3. Select the "Remote" tab.

  4. Select the Allow remote connections to this computer radio button.

  5. Click Apply.

  6. Click OK.

Windows Server 2008

  1. From the Windows desktop, select Start > Administrative Tools > Server Manager. The Server Manager window appears.

  2. In the "Computer Information" section, click Configure Remote Desktop. The System Properties window appears.

  3. Select the "Remote" tab.

  4. Select either Allow connections from Computers running any version of Remote Desktop (less secure) or Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure).

  5. Click OK.

Back to top

Feedback and Knowledge Base

(thinking…)