I've managed to solve this problem.

First, ipv6 was a red herring. I just got lucky that the ipv4's kept being assigned in the right order.

The real issue was that, when there are multiple VPNs, there is a little selection window that allows you to specify which VPNs the client specific override is assigned to. This determines which folder the config file is written to.

I found out the csc was written to the wrong location, because when making a second client override, the configuration will default to selecting the next server, not the one you selected last.

@JKnott Thank you. I believe I have been able to resolve this. The solution was to push a route via OpenVPN along with having additional phase2 IP routes specified.

I did not set the default route for the Remote Site Office to use the Remote Office as I wanted general internet traffic to avoid the VPN.

So far, this appears to be working as required.

Matthew

I did this, but the directory config-auto was not created and I had to make the manually.
Make sure that the service is automatic and the GUI does NOT auto load when logging in.
https://openvpn.net/community-resources/configuring-openvpn-to-run-automatically-on-system-startup/

@bitvoip

well great! Always good to discover and fix problems.

@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/24

Factory01
(Server OpenVPN Factory02): IPv4 Remote network(s): 10.10.3.0/24
(Client OpenVPN Azure): IPv4 Remote network(s): 10.10.1.0/24

Azure:
(Server OpenVPN Factory01): IPv4 Remote network(s): 10.10.2.0/24,10.10.3.0/24

At 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.

@stephenw10

I deleted the TCP clients as I couldn't get rid of the errors. Looks okay now w/o the TCP clients.

@viragomann

The client IPs are being assigned in FreeRadius.

One place to setup a user as opposed to both FreeRadius and then CSO. The IPs are being assigned correctly so I expect the outcome is the same as if I was using CSOs

@McMurphy said in Able to ping via address NOT via subnet:

The destination is a network connected via OVPN routing the subnet 10.27.40.0/24

When I set the destination as SMMC subnets I am unable to contact the destination.

These are different networks for sure.

Seems the SMMC is the VPN tunnel pool of the server, which your client is connected to. So "SMMC subnets" are just the virtual server IP and the connected clients.

If you want to allow access to 10.27.40.0/24, however, you have to state this subnet as destination naturally.

@viragomann
Thank you so much for your reply. now i understand it. thank you for the exact informations!

many greets markus

@McMurphy
Yes, for sure you can state a larger subnet, which includes all needed.

However, to avoid conflicts, especially if you connect other locations via VPN to your network, either for user access or site to site, I'd set the network only as large as necessary and range the subnets closer.

You have currently 10 used /24, while there are 81 x /24 in the gaps in between.
You could use 10.27.0.0/20 which gives you 16 x /24 subnets for instance.

Thank you both for your valuable suggestions.

The issue was resolved by setting the pfSense IP as DNS.

The IP 192.168.1.210 is that of the domain controller which is not blocked by the firewall but I presume it does not respond to requests coming from hosts via VPN (?)

Problem solved.
Outbound NAT rules where not created by the wizzard. Duplicating rules for the fisrt server but on UDP 1195.

@coreybrett Yes it’s just another option to offload encryption.