@mainzelman it works ! I have created on FW-B rule: LAN -> OVPN2 for it. Whatever before there was nothing to be seen in the FW logs. <don't always believe what you see ;-))>

Go back to auto, deleted all the other rules. then go to hybrid and create your rule for your boubound nat for your vpn. [image: 1612088293164-hybrid.png]

@daddygo 192.168.38.1 is LAN IP The PF-Sense is connected via a DynDNS Name 10.x.y.z is nessesary cause we are running a bunch of offices - 192.x.x.x does no longer serve us. We are changing all up to 10.X.Y.Z but till everything is up I need to connect the old firewalls with the new ones :-) Later on everything will be changes to 10.x.y.z :-)

@rico thanks wasnt shure ! lets keep it a bit more strict "clean" .... i dont wanna know how many more of these classy "iDontKnowJackRules" i m gonna find on thes boxes ;) brNP #stayHealthy

@griffo Yes about the prevention of traffic leaks.

@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 : [image: 1611558159451-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 : [image: 1611558342015-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