- VM and VCL attached to same Azure Virtual network
- Subnet created for LAN
- Azure VCL and VM attached to same subnet
- Ping between VM and Azure VCL works
- Azure VCL Lan and Lock(s) In same Access Group
- Layer3 Connected Lock
Usually it is desired to have connection from TOSIBOX® Virtual Central Lock LAN to connected Layer3 Lock´s LAN network.
In Azure users have to create specific Routes for connection to work. Connection in Lan between VCL and VM will work without manual routes.
But connection from VM, in this case Windows 10, towards Lock´s LAN via VCL requires the route.
Lock LAN: 22.214.171.124/24
Lan between VM and VCL: 126.96.36.199
Azure will reserver first 5 addresses.
VCL Lan interface IP-address: 188.8.131.52
In Azure control panel, Go to your Resource Group. Create new [Route Table] and give it a name.
After [Route Table] is created go to your Resource Group and find your [Route Table], open it and go to: Routes.
Klick +ADD and create route.
- Give Route a name, if this is a single route to single Lock, Lock Mac address may be good telling name.
- Address prefix, is the network you want to route to, in this case LAN network behind Layer3 Lock.
- Next Hop type, choose Virtual Appliance.
- Next Hop Address, give VCL LAN IP-address
Next go to Subnets, under [Route Table]. Click +Associate
Select Correct Virtual Network, then select correct subnet.
At this point Routing from VM-Windows to Lock-Lan will work.
If you do not want to create Own route to every Lock in this LAN, you can create larger route for example: 184.108.40.206/255.255.0.0. But for this to work, Lock LAN has to fit under this large network. If Lock LAN cannot be changed 1:1 Nat is available for use.
Problems with Cloud based VMs (Azure and AWS) connect to a VCL to access Locks network
The Virtual Machine could not ping or connect to devices on the Locks network. Tosibox identified that the ping reply was arriving at the VCL, send to the Locks network, coming back to VCL and VCL send it out to the LAN1 interface. But nothing arrived at the VM
Solution 1 (Example for Openstack platform and IP-Subnet for Locks: 220.127.116.11/24):
Problem is found in the creation of the virtual network on cloud site: the virtual network (Vnet): the network did by default not allow a virtual machine (the VCL) to send packets with a different source IP-address onto the network. The solution was to allow the virtual NIC of the VCL to send packets with source addresses in the 18.104.22.168/24 subnet. This was done with the following terminal command:
$ openstack port set <ID of VCL NIC> --allowed-address ip-address=22.214.171.124/24/24”
You have to add Locks LAN subnet additionally in VCL access group as added IP range.
You have to manually create the route tables in your EC2 instance to the Locks LAN network
Solution for Amazon AWS Cloud installation: