@madbrain Anyone ?

@viragomann I lost patience and just rebuilt the OpenVPN tunnel completely. In hindsight, I suspect that merely reimporting the TLS key from the server on the client side would've done it. Thanks very much for your help.

@codechurn said in Open VPN Server:

I didn't realize that OpenVPN required me to install a client to use it

Not really needed, but as Microsoft products like to talk with Microsoft Products, its the same for OpenVPN product.
You can of course use any 'OpenVPN' client, as long as it is compatible with OpenVPN, and you manage to make it work ^^

But it works, and during massive home works situations around 2020/2021/2022 it was fully tested.
Half the planet was using it.

@Luvirini said in OpenVPN daemon stops working:

2.7.1

?,

You've re invented the reason why "2.7.2" came out 😊

@Luvirini said in OpenVPN daemon stops working:

to autostart services that have crashed

The system blow up tool ? This one :

7ca9edc3-7ed9-4bba-bf38-a9fa6e363c13-image.png

? Won't help you very much.
VPn will blow up, core dumps, OpenVPN gets restarted, rinse and repeat.
After several cycles, system stability can become an issue.

Just upgrade to 2.7.2 and call it a day.

Service_Watchdog is useful for system developers, so they do not have to baby-sit their "not-ready-code" all the time.

Edit : Just to motivate you : I'm using pfSense, and OpenVPN server for more then a decade. Never had it seg-fault on me.

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 (?)