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

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

So additionally I've disabled the OpenVPN and recreated the tunnel using IPSec and it's still having the same issue..

@The-Party-of-Hell-No - thanks for your input This is what I have : [image: 1715244761531-49f1e450-dc52-4847-b4ca-5e7f6948c230-image.png] Servers are setup but the problem is that both servers 'PUSH' the same ifconfig and route-gateway numbers, so they clash when both are on simultaneously. I can filter and redefine them to be on separate subnets but I don't get web as the server for each one is still on 10.100.0.1 and not on the subnets (10.1.10.1 and 10.1.11.1) Have you split your multiple simultaneous profile connections over separate subnets? I think I'm missing either a key openvpn client command I'm not aware of to redirect the gateway to be a specified ip, or another different way of doing this completely. Again - thanks for any advice or pointers you can give!

Interestingly, the OpenVPN Client end is quite happy to have no tunnel specified. So, as an experiment I commented out the line of code that was producing the error (line 612 in /usr/local/www/vpn_openvpn_server.php) and then configured the OpenVPN Server with no tunnel address. Everything appears to work perfectly. I have an OpenVPN tap mode tunnel, connect it to a bridge and it works as expected. So how am I supposed to do this without messing with the code? Tim

@jimp said in OpenVPN CA expiring, impacts of renewing it?: If the CA is not yet expired, then renewing the CA and reusing the serial number will allow existing clients to work until the CA expires, while new clients you roll out can also connect to the same server. Okay so I think I understand. 1> Renew CA with same serial #, certs will be recognized by existing clients but only until original CA expiration date. 2> Roll out new configs with new CA cert and those will work now until the new CA expiration. I really appreciate the help Thanks -S

@Shack Take a look similar, protonvpn or mullvadvpn have updated guides to set up openvpn or wireguard. All the same)))

@viragomann That actually sounds like a proper idea. not happy with this vpn service at all.. thanks for your help, I think I'll go that route this has not got me very far, just have to find a good VPS and go with that thanks