-1

Multi-hop routing I'm trying to communicate from the tx.py program to send packets (UDP) down to device 1 and device 2 shown in the picture. Currently we have OpenVPN clients running on 2 of our VMs and if I run tx.py on those vms I can communicate fine to each device that is connected to that vpn tunnel (so from vm2 I can reach device 1, but not device 2).

I want to be able to route from vm1 so that I can send to device 1 or device 2 from this central location. I tried adding a route on vm1 to device 1 (via VM 2) like route add -net 100.64.226.0 netmask 255.255.255.0 gw 10.2.6.20 dev eth0 but was still not able to receive packets on Device 1. Also tried toggling ip forwarding on for both vm1 and vm2 but this didn't fix it.

What is the way to do this?

Note that I don't need to communicate back up from the devices to vm1.

Note: I don't control the openVPN servers and cannot change configs there.

Fraggle
  • 61
  • 1
  • 2
  • 10
  • I see 1 downvote on this. If you have suggestions on how to improve the question, please make a comment. – Fraggle Apr 22 '21 at 15:29
  • It would be wasier to start an OpenVPN client on VM2, connecting "OpenVPN Server 2". This way, you don't need to fiddle with routes at all. As a side note, you _do_ need the devices to be able to communicate back to the VMs, otherwise not even the TCP handshake would work. – Lacek Apr 22 '21 at 18:02
  • About the downvote: I see a lot of otherwise OK questions downvoted recently, yours included. Someone seems to have found a new hobby. – Lacek Apr 22 '21 at 18:03
  • @Lacek there are some other reasons why I don't want to connect VM2 to OpenVPN Server 2, but otherwise yes that would work and I could run my tx.py from VM2 to reach both device 1 and 2. As for TCP handshake, we are using UDP so I don't think there is one (right?). – Fraggle Apr 22 '21 at 18:46
  • Could you please explain what kind of routers are in between the devices, also what kind of VMs are you running? As the solution to your question will be dependent on what flavour of linux you are running. – Barnabas Busa Apr 26 '21 at 15:03
  • The VMs are CentOS flavor Linux. The routers, are whatever Microsoft Azure Cloud uses (I don't think they expose that information). If the answer is not known for Azure setup then knowing how it would be done on aws might help get us closer at least. The machines shown in the picture that are part of Azure Vnet are all VMs, but I suppose they have other network devices not shown as part of the glue between those. – Fraggle Apr 26 '21 at 18:56
  • 2
    try to add iptables -t nat -A POSTROUTING -s 10.2.6.20/24 -o eth0 -j MASQUERADE. on vm2 – Danila Ladner Apr 27 '21 at 05:02
  • Routing is forwarding packets from one network to a different network, but you have the same network everywhere. Forwarding in the same network is bridging. A host will use its mask to determine if the destination is on the same or a different network to build its frame for the destination (same network) or gateway (different network). Trying to route fro a network back to the same network is wrong, and you need to look at bridging, not routing. – Ron Maupin Apr 29 '21 at 14:03
  • 1
    Do you have packet forwarding enabled on VM2 and VM3? – kupson Apr 29 '21 at 14:17
  • @DanilaLadner yes this is part of the solution, although for us it is "-o tun0" instead of eth0. There is also a separate routing table configuration that is needed on the Azure subnet/vnet level which cannot be done on the vm but is possible via the Azure portal. I'll post more details soon. – Fraggle Apr 30 '21 at 17:50

2 Answers2

1

As far as I can see, this is not possible without changing Openvpn Server configuration.
I have implemented similar scenarios with certificate based authentication, and it is working. I am assuming this is a road-warriro setup and not a site-to-site connection. Which means, the VPN Server is only aware of a single client and not of other machines trying to connect over the same client. From a security perspective this also makes sense for me.
Now if more machines need to connect over the client computer, it will then act as a gateway, and this can be configured at the Openvpn server. Details instructions on setting this up can be found here:

Expanding the scope of the VPN to include additional machines on either the client or server subnet.

See: Including multiple machines on the client side when using a routed VPN (dev tun)

Diamond
  • 8,791
  • 3
  • 22
  • 37
0

You need to setup User Defined Routing by using a route table connected to the 10.2.6.0 subnet so that Azure knows to route to 10.64.226.0 through 10.2.6.20 and similar for device 2. You will still need to ensure the routing (IP forwarding) features are enabled in the Azure network adapters, OS network adapters, and the OS routing tables (in both directions).

https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table

Azure automatically routes traffic between Azure subnets, virtual networks, and on-premises networks. If you want to change any of Azure's default routing, you do so by creating a route table.

https://petri.com/implementing-azure-user-defined-routing

If you use an Azure gateway for VPN connectivity, the local network setting will provide your subnets with a route to your on-premises network. However, when you deploy your own VPN solution in a virtual machine (that’s what a virtual appliance is) then there is nothing, by default, to tell Azure how to route subnet traffic to the on-premises network(s).

There are many examples online, mostly related to next generation firewalls (i.e. force Azure to route through your firewall appliance), and Hyper-V (i.e. setup Azure to route to an internal Hyper-V network through the virtual Hyper-V host).

Doug
  • 842
  • 4
  • 7
  • Yes, User Defined Route, plus ensure IP forwarding enabled both at Azure level and VM level, plus the suggestion (slightly modified) by Danila Ladner to add "iptables -t nat -A POSTROUTING -s 10.2.6.20/24 -o tun0 -j MASQUERADE. on vm2". Without this last piece (iptables), vm2 for example will receive the packets from vm1 (verified with tcpdump) but they won't get forwarded through the OpenVPN client. Note that for User defined route you can select "Next Hop Type" as "Virtual Appliance". – Fraggle May 04 '21 at 20:49