Trouble with Isolated Networks

[Firebird89]

This is a set of ping tests from various deployment types in my vCloud 5.5 environment.  In most cases the traffic flows as expected.  The only place that we’re having trouble is getting traffic to flow though a NAT set up to an isolated network.  For these examples we have the following network parameters.  Firewalls have been disabled between all devices and hosts.  Anyone have any ideas where I can look or what might be messing with my traffic?

              

Network/Device	IP Address/Network	Default Gateway
Routed DTST Network	192.168.10.0/24	192.168.10.1
Routed RSCH Network	192.168.11.0/24	192.168.11.1
External Network	192.168.62.0/23	192.168.63.3
External Test Server	192.168.63.205	192.168.63.3

Scenario 1:

Net new VM in DTST on the Routed Network with an IP from the vCloud Static IP Pool - 192.168.10.9

                 

Ping Source	Ping Destination	Status
192.168.10.9	192.168.63.205	SUCCESS
192.168.63.205	192.168.10.9	SUCCESS
192.168.10.9	192.168.10.1	SUCCESS
192.168.10.9	192.168.11.1	SUCCESS
192.168.10.9	192.168.63.3	SUCCESS

Scenario 2:

Net new VM in a fenced network deployment with NAT.  Again the IP of the VM is pulled from the vCloud Static IP Pool - 192.168.10.9.  The external IP of the VM is also pulled from the same pool - 192.168.10.11

                 

Ping Source	Ping Destination	Status
192.168.10.9	192.168.63.205	SUCCESS
192.168.63.205	192.168.10.11	SUCCESS
192.168.10.9	192.168.10.1	SUCCESS
192.168.10.9	192.168.11.1	SUCCESS
192.168.10.9	192.168.63.3	SUCCESS

Scenario 3:

Cloned imported VM in a fenced isolated network deployment with NAT.  The imported VM has an imported IP of 192.168.63.177.  The external IP of imported VM in the DTST Routed Network - 192.168.10.3

                 

Ping Source	Ping Destination	Status
192.168.63.177	192.168.63.205	FAIL
192.168.63.205	192.168.10.3	FAIL
192.168.63.177	192.168.10.1	SUCCESS
192.168.63.177	192.168.11.1	SUCCESS
192.168.63.177	192.168.63.3 (iso network GW)	SUCCESS

Scenario 4:

Imported VM that has been unaltered but is under vCloud Director Control and attached directly to the External Network with no routing or NATting.

                 

Ping Source	Ping Destination	Status
192.168.63.177	192.168.63.205	SUCCESS
192.168.63.205	192.168.63.177	SUCCESS
192.168.63.177	192.168.10.1	SUCCESS
192.168.63.177	192.168.11.1	SUCCESS
192.168.63.177	192.168.63.3	SUCCESS

[_morpheus_]

Can you run a packet sniffer on the test server 192.168.63.205 and see if the ping packets are making it there?

[cfor]

Another test I would do it place the two failing hosts on the same host, also migrate the edge device to that host (so all traffic is host local).

If that works then the issue might be something with the vlan routing that is backing the isolation.

Also... what type of network pool is this backed with?  VLAN, VCNI, VxLan, NSX?

[IamTHEvilONE]

So what you are saying is that you imported a VM into a network that is based on 192.168.10.0/24, but it has an IP of 192.168.63.177 and you didn't customize it.

Firebird89 wrote:

Scenario 3:

Cloned imported VM in a fenced isolated network deployment with NAT.  The imported VM has an imported IP of 192.168.63.177.  The external IP of imported VM in the DTST Routed Network - 192.168.10.3

                

Ping Source	Ping Destination	Status
192.168.63.177	192.168.63.205	FAIL
192.168.63.205	192.168.10.3	FAIL

So the router will have a rule set based on 192.168.10.0/24 (10.1 - 10.255) ....

Did you re-customize this guest to say the Default Gateway is 192.168.10.1?  Ideally, you would want to re-customize the guest to actually use an IP from the 192.168.10.0/24 network. so that it's part of the actual network schema, not some manual IP given by something else.

The ping works to 192.168.10.1 probably because it'll see the ICMP request and reply, as it's the only gateway on the inside of the NAT network.

From the outside in 10.3 -> 192.168.63.177 would fail since the return route won't use the correct gateway given the VM configuration.

If the 192.168.11.1 is a routed network on the same edge gateway device, then it might work since it's internal to the GW and a known address.

the last one I can't explain in scenario 3 without seeing an actual network topology, and complete IP config of the source NIC Card, nat rules (SNAT vs 1:1, etc)

[_morpheus_]

I guess we need clarification on what he did. Is the vApp really fenced or is it a vApp with routed vApp net? Can we get screenshots of the vApp - VMs tab, network tab, and network configuration (NAT, firewall, etc.)