@adelphi

Sorry for bumping such an old topic, but it's very relevant.

I can't understand why your method didn't work for me, as it makes perfect sense. It's even weirder that what I came up with did work. After firewall rules failed to achieve the desired result, I tinkered elsewhere. Here is a NAT Port Forward rule that achieved the same goal.

Interface: LAN
Protocol: UDP
Source: Any (this is default)
Source Port: Any (this is default)
Destination: WAN address
Destination port range: 1196 (our VPN port)
Redirect target IP: Random private IP address that is NOT part of your LAN network. I used 192.168.1.254, but our LAN network is 192.168.21.0 / 24
Redirect target port: I just chose a random port. 45534

I was surprised that it even let me create this rule, but doing so made it so people who are connected to the LAN can no longer connect to the OpenVPN server while people connecting to the VPN from outside the office are unaffected.

It isn't something you'd check directly like that. Setup a VPN using that cipher and run a speed test across it. Try a couple different types of AEAD ciphers and compare.

IPsec can use AES-GCM
WireGuard uses ChaCha20-Poly1305
OpenVPN supports both AES-GCM and ChaCha20-Poly1305

@ali-ghabsha said in OpenVPN Unable to contact Deamon, Service not running:

2.4.3 the openvpn works

Be careful : when you export a config ( with the OpenVPN client EXE in the config if you use that one also ) you change the OpenVPN version used. Mixing OpenVPN client software on client and or server side can have issues.

@ali-ghabsha said in OpenVPN Unable to contact Deamon, Service not running:

the openvpn doesn't work, so it's a version issue, why the old version works but the new one no

What do you mean by doesn't work ?
I can only find this in your log :

@ali-ghabsha said in OpenVPN Unable to contact Deamon, Service not running:

GDG: problem writing to routing socket

This https://community.openvpn.net/openvpn/ticket/688 ?

I don't have that GDC message :

2cc1b805-3779-48d4-ad8b-5e49a0e43d1a-image.png

You can see it starts to listen on :
UDPv4 link local (bound): [AF_INET]192.168.10.3:1194
192.168.10.3 is my WAN interface - WAN IP - I have an ISP router in front of my pfSense.

The start up shown is a clean start up of OpenVPN

This is the WAN firewall rule :

babbf6c7-7a77-4d88-a4a6-8717af6143e4-image.png

@ali-ghabsha said in OpenVPN Unable to contact Deamon, Service not running:

If we check the logs we find there's an error related to the Wan interface regarding the openvpn ....

and what about showing these errors ?

@ali-ghabsha said in OpenVPN Unable to contact Deamon, Service not running:

Why if I upgraded from the old version to the new version the openvpn works but users behind pfsense can't access the internet.

So, OpenVPN starts, there is a related firewall rule on your WAN, and devices on LAN do not have any Internet access any more.
I'm curious how you set up your system.
Adding the OpenVPN firewall rule on WAN doesn't implicate at all LAN's Internet access - OpenVPN server running, or not.
Running OpenVPN server with or without the firewall rule on WAN doesn't change OpenVPN behaviour (no messages or warnings). Without the firewall it just isn't accessible. This will not alter anything for devices on your LAN.

@ephi
Driving an OpenVPN server on LAN VIP works definitely. I did that already. The only part, I'm not familiar, is your "special HA setup" with CARP on LAN only.

@viragomann yes internet is working on pfsense machine, however machine is down yet , i'll share the logs after some hours.

@dex
Yeah, the routes to your home LAN my work, but it is not ideal to set static routes. Instead you should use the Remote Networks box in OpenVPN.

However, so the request packets destined to your LAN are directed over the VPN and may reach the LAN devices, but latter will send responses to their default gateway, but not back to Unraid. That's why the default gateway should be the VPN endpoint at all.

If you want to get it work this way, you need to do masquerading on the Unraid on packets destined to your home LAN, so that it translate the source addresses in packets going to LAN devices into its LAN address. Only this ensures that responses are coming back.

Hi,

Sorry for the late response. I did something similar and then I added it as a shellcmd. This is the specific shellcmd I use right now.
The SHA512-sum is updated whenever the source is updated. If it differs it means one of two things :

I have already modified the file. A new version of this file was released.

I will notice 2 by my VPN not working, and then just update the SHA512-sum.

Here it is in case someone wants to use it:

(/sbin/sha512 -c bbf2919171bf06301f4cbbefa11b61e7aff7538a70d95d081e96c66ebc032a4ba40f7c804eef5b6cf47bcc0346de422e40db0b9e6c11ded14f41196c7c02eeb1 /usr/local/sbin/ovpn_auth_verify >/dev/null; if [ $? -eq 0 ]; then /usr/bin/sed -i "" 's,sbin/fcgicli -f,bin/php-cgi -q,g' /usr/local/sbin/ovpn_auth_verify ; fi)

Just add it as a shellcmd.

It simply compares the SHA512-sum with a static one, and if it's the same (i.e. original known/unmodified), replaces the use of fcgicli with php-cgi in the file.

Works as it should for me.

Note: This isn't a real "fix", it's a workaround until the bug gets fixed, regardless of if that means a fixed fcgicli binary, using php-cgi or something else.

And yes, I know about that bug report. I'm following any changes in it.

// Stefan

@flsnowbird Please attach /tmp/rules.debug before/after connecting OpenVPN client

@marimo hi marimo i had the same tls key error by referring to your solution i disabled the block private networks and loopback address in wan interface setting but still getting the same error can anyone help me out.

@netblues it appears on all OpenVPN connections. I've chosen the one that has the best UMTS signal level, so to avoid disconnections for low signal

@ali-ghabsha said in OPENVPN stopped working after upgrade:

The modem is configure to forward the udp 1194 port from the public ip to the private ip of the pfsense,

That would be a typical ISP device that contains a modem part, for example to convert ADSL POTS signals to Ethernet - and a router part that has to contain the NAT rule.
A modem by itself could not contain NAT rules.

If the upstream ISP router/modem works fine, you could packet capture port 1194, UDP on the WAN interface of pfSense and see the incoming OpenVPN packets.

@ali-ghabsha said in OPENVPN stopped working after upgrade:

shows Wan error 18 or 19 or 148, or 150....

Who what shows these errors ?

@ali-ghabsha said in OPENVPN stopped working after upgrade:

Then if you decided to delete the rule of the vpn in the Wan tap... And recreate it...

What changed ?
Nothing special about this rule :

66a67f3e-f8de-465c-a992-4339b1ac458e-image.png

First :

@ali-ghabsha said in OPENVPN stopped working after upgrade:

I had pfsense 2.4.3, which I've upgraded to 2.4.5, after upgrade the openvpn clients were unable to connect,

Then :

@ali-ghabsha said in OPENVPN stopped working after upgrade:

after the upgrade the VPN works

It's time to tell more about your setup.
Time to answer the questions.
A WAN firewall rule as shown above can not block LAN users.

@teamits Nice one, thanks to you both for the answers

I manage in solving my issue.
here is my diagram:
diagram.png
I needed mainly two settings:

on pfsense2 I had to check "Bypass firewall rules for traffic on the same interface" option otherwise my WAN routing rules were ignored;
2, defining a NAT outboud rule on pfsense1:
nat-outbound.JPG
The unwanted aftermath was that the whole traffic between the networks was allowed and I had to design some extra block rulesets to allow only what I really need. But in the end nothing hard.
Now everything works nice and fast!

It's working again after restoring from my most recent backup.

No clue what went wrong before.

I've turned off hardware acceleration in OpenVPN server and it does look like the speed increased, but it also looks like my network isn't getting the right speeds so I can't tell what I'll get until that's fixed by the ISP.

I did go from 5Mb/s to 20 though, so that's a good sign.

@bob-dig And you can port forward towards localhost? Have never done this.

Sure why wouldn't it? Localhost is a normal interface. 127.x.x.x are "normal" IP addresses. No reason why a service or daemon shouldn't run or listen on localhost or a localhost-style IP address. Many developers e.g. in Ops or DevOps use local development tools and servers to test on their own machines (because faster) and bind e.g. a web-stack for rapid development to localhost. OpenVPN isn't really anything special in that consideration.

Also it's really one of the defaults to run an OpenVPN server on localhost when dealing with MultiWAN. You don't want two different servers for every WAN but same IP space, same settings, same certs etc. so easiest way is to "bind" it to localhost so it is awaiting traffic and just use two port forwards on the appropriate interfaces to direct traffic to it from those WANs. The same could be done with your internal WiFi network, too. Plus side is, that port forwards also use "reply-to" parameters of pf so traffic should always return the way same way out it "got into" the OVPN server in the first place.
We've customers running 4 DSL and 1 fibre line and for easier migration we configured their OVPN server to listen on localhost and redirect traffic from all those WANs to it. So if anyone is still using an old DSL IP it's still working :)

Multihome should make that configuration easier and also add multi-link support for IPv4+IPv6 but somehow multihome still makes trouble when running. Either in selecting the wrong IP family or in some other fashion like your problem that doesn't really make much sense...

I had the same issue with OpenVPN (pfSense 2.4.5-RELEASE-p1) and AMD GX-420CA SoC CPU.
Downloading anything with speed higher than 200 Mb/s causes packet loss of over 20% until VPN_WAN Gateway goes offline.
The best solution I've found is to use Traffic Shaper (not Limiter)
I follow this guide and put 200 Mb/s as my download speed in step 6
After that, packet loss stops at 3-5% when downloading with maximum speed of 200 Mb/s