OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server)
-
Hello!
We currently use OpenVPN (site-to-site, on pfSense) between factories and Azure, with Azure being the main server for accessing systems.
One of the factories recently, started to experience latency that has been causing a headache.Factory01(client) <-100ms-> Azure(server)
Factory02(client) <-170ms-> Azure(server)Does anyone know if it is possible to perform the configuration below in OpenVPN, taking advantage of the low latency between factories and lower latency between Factory01 and Azure?
10.10.3.0/24 <-> 10.10.2.0/24 <-> 10.10.1.0/24
Factory02(client) <-45ms-> Factory01(server/client) <-100ms-> Azure(server)The idea would be to reach the 10.10.1.0/24 (Azure) on network 10.10.3.0/24 (Factory02) passing through 10.10.2.0/24 (Factory01).
Thanks.
-
@rschossler
Of course it's possible. It's just a thing of routes.
But not sure if the latency would really be much better. Do you have the 45 ms between the factories over a VPN?Are there any packets losses between factory02 and Azure?
I'd sniff the traffic to check if there is something wrong on the line, also the OpenVPN traffic on the WAN. -
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Of course it's possible. It's just a thing of routes.
In the OpenVPN settings of Factory02, in IPv4 Remote network(s), set 10.10.1.0/24,10.10.2.0/24.
In Custom options, entered push "route 10.10.1.0/24 255.255.255.0" but did not create the entry in the routing table (Diagnostics > Routes).
Again, in Custom options, enter route 10.10.1.0 255.255.255.0 10.10.2.1. This time the entry was created in the routing table, but without success in reaching 10.10.1.0/24.
In Firewall > Rules > OpenVPN, a rule was created allowing IPv4*, without success.@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
But not sure if the latency would really be much better.
In a test carried out with the same internet link at Factory02 (OpenVPN Client from Factory01), forming the same circuit [Factory02(client) <-> Factory01(server/client) <-> Azure(server)], there really was no improvement.
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Do you have the 45 ms between the factories over a VPN?
Yes, it has worked well.
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Are there any packets losses between factory02 and Azure?
No packet loss.
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
I'd sniff the traffic to check if there is something wrong on the line, also the OpenVPN traffic on the WAN.
Recently we had meteorological problems that affected several communication services, but as there was no gain in the test carried out above, I will look for another alternative.
Thanks.
-
@rschossler
There is no need to push routes to a client in a site to site setup. And even don't push or set routes in the custom options at all. pfSense provides the "Local Networks" and "Remote Networks" for this purpose.So in the settings of Factory02(client) enter 10.10.1.0/24 into the "remote networks" box.
And on Factory01 in the OpenVPN server settings, which Factory02 connects to enter 10.10.3.0/24 into the "remote networks" box.
And on Azure you have to route both subnets to Factory01 now. So you have to enter "10.10.2.0/24,10.10.3.0/24" into the "remote networks" box.
-
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
So in the settings of Factory02(client) enter 10.10.1.0/24 into the "remote networks" box.
And on Factory01 in the OpenVPN server settings, which Factory02 connects to enter 10.10.3.0/24 into the "remote networks" box.
And on Azure you have to route both subnets to Factory01 now. So you have to enter "10.10.2.0/24,10.10.3.0/24" into the "remote networks" box.
This was the first test, without the Custom options.
I believe that because the 10.10.1.0/24 network is available on the Azure server and not on Factory01, OpenVPN in Factory02 was unable to reach and create the route.First configuration:
Factory02
(Client OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.1.0/24Factory01
(Server OpenVPN Factory02): IPv4 Remote network(s): 10.10.3.0/24
(Client OpenVPN Azure): IPv4 Remote network(s): 10.10.1.0/24Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.3.0/24 -
@rschossler said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.1.0/24,10.10.2.0/24The first one is local according to your above statements.
-
@viragomann said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.1.0/24,10.10.2.0/24Sorry, I just wrote it wrong.
The correct thing would be:Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.3.0/24 -
@rschossler
So I would expect the routes to work.If not, check in the routing tables of all involved nodes if the routes were added properly.
If any is missing check the log for the reason.
-
@rschossler said in OpenVPN: Factory01(client) <-> Factory02(server/client) <-> Azure(server):
Factory02
(Client OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.1.0/24Factory01
(Server OpenVPN Factory02): IPv4 Remote network(s): 10.10.3.0/24
(Client OpenVPN Azure): IPv4 Remote network(s): 10.10.1.0/24Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.3.0/24At first, I was carrying out a configuration with a test server, but the configuration did not work under any circumstances.
Without success in the research, I carried out the configuration in the production environment and it worked.
Even with the higher latency, OpenVPN communication from Factory02 through Factory01 was more stable with Azure.