In order to double-check what I am saying, I just created a new Stein Packstack. The Packstack server is a KVM virtual machine, bridged to my home network 192.168.1.0/24. It's IP is 192.169.1.202.
Packstack set up as follows:
sudo packstack --debug --allinone --default-password pw \
--os-neutron-ovs-bridge-interfaces=br-ex:eth0 \
--os-neutron-ml2-tenant-network-types=vxlan \
--os-neutron-ml2-mechanism-drivers=openvswitch \
--os-neutron-ml2-type-drivers=vxlan,flat \
--os-neutron-l2-agent=openvswitch \
--provision-demo-floatrange=192.168.1.0/24 \
--provision-demo-allocation-pools '["start=192.168.1.240,end=192.168.1.254"]' \
--os-heat-install=y --os-heat-cfn-install=y
(exactly as https://ask.openstack.org/en/question..., except for the IP addresses).
--os-neutron-ovs-bridge-interfaces=br-ex:eth0 means that the eth0 interface is plugged into the external bridge, thereby connecting the cloud to the home network.
--provision-demo-allocation-pools sets the IP addresse ranges used for floating IPs.
The packstack command provisions two networks: External network public and a tenant network private, which belongs to the demo project.
The Packstack host's br-ex has two IP addresses. I am puzzled about 192.168.1.1; it's the same address as my home router. I removed this address from br-ex and have not seen any problems so far.
192.168.1.202 is the original IP address of eth0.
6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 52:54:00:dd:2c:f3 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.202/24 brd 192.168.1.255 scope global br-ex
valid_lft forever preferred_lft forever
inet 192.168.1.1/24 scope global secondary br-ex
valid_lft forever preferred_lft forever
With this setup, I can create an instance attached to private, give it a floating IP from the 192.168.1.240-192.168.1.254 range, and can access the instance from outside. My topology:
$ openstack server list -c Name -c Networks
+--------+----------------------------------+
| Name | Networks |
+--------+----------------------------------+
| testvm | private=10.0.0.96, 192.168.1.251 |
+--------+----------------------------------+
$ openstack router show router1 -c external_gateway_info -c interfaces_info --fit-width
+-----------------------+----------------------------------------------------------------+
| Field | Value |
+-----------------------+----------------------------------------------------------------+
| external_gateway_info | {"network_id": "5ab6e727-4ca7-48df-8a4e-e59fcba1e48f", |
| | "enable_snat": true, "external_fixed_ips": [{"subnet_id": |
| | "68eb7a3d-9498-4e77-8c9f-26c07e35104a", "ip_address": |
| | "192.168.1.245"}]} |
| interfaces_info | [{"subnet_id": "a68c38da-22dd-48c1-bc8b-12262ed4a1c6", |
| | "ip_address": "10.0.0.1", "port_id": |
| | "d1a839e8-ce7d-4788-85b3-4875a1fc2f76"}] |
+-----------------------+----------------------------------------------------------------+
From a Windows PC in my network (bad round trip times, but I don't mind):
$ ping 192.168.1.251
PING 192.168.1.251 (192.168.1.251): 56 data bytes
64 bytes from 192.168.1.251: icmp_seq=0 ttl=63 time=8.941 ms
64 bytes from 192.168.1.251: icmp_seq=1 ttl=63 time=2.108 ms
64 bytes from 192.168.1.251: icmp_seq=2 ttl=63 time=3.909 ms
--- 192.168.1.251 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.108/4.986/8.941/2.892 ms
The router's gateway address, 192.168.1.245, can also be reached from a device external to the cloud.
I don't know what is different in your setup. My suspicion is that you need to configure something with VMware ... (more)
The problem is stated in the error message: There is no route to this address.
If your local address is 192.168.1.69, and your network prefix is 24, 192.168.3.142 is in a different network, and you need a router between the two networks.
I suspect, however, that 192.168.3.142 is a static IP.
If the router you talk about is a Neutron router, it does not route traffic from outside to static IP addresses (192.168). Even if it does, you would have to set up your routing table so that this router is used.
The real solution is associating floating IPs with your static addresses.
i tried with a floating ip also but no luck with that
Focus on fixing instance access via floating IP. Static IP addresses are not supposed to be reachable from outside the cloud.
I can't comment on the VLAN problem without knowing error and log messages. Is VLAN configured at all? You may want to create a separate question for this problem.
If 192.168.13.0/16 is the address range of a tenant network, these addresses are not supposed to be reachable from outside. The concept of floating IPs exists for precisely this purpose: Reach instances from outside the cloud.