@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 : [image: 1611209273604-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: [image: 1611162850942-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: [image: 1611163192760-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

@jingles You just want to review that section and verify that traffic matched on that rule is being routed thru the default gateway instead of the VPN gateway.

@skilledinept https://forum.netgate.com/topic/131539/how-to-restart-openvpn-in-a-script/5?_=1610913942448

I finally get it to work!! It was a problem with a configuration of an IPSec tunnel that I had previously on one end. It turns out that although it was disabled, it has configured the subnet 10.0.18.0/24 So I assume that this configuration is not supported and having the same subnet on these different services could cause the issue. Thanks @viragomann for your help :) I really appreciate mate [image: 1610834091669-a2bf89a8-7362-47b3-b3d2-742cc7070184-image.png]

@netblues That would be the issue. It is strange that the entire config worked without the semicolons until I added those lines. Nevertheless, it appears to be working normally now. Thanks.

@viragomann Tnx for your help in trying to get this sorted. There was an additional layer to this problem which was as @NogBadTheBad stated the pfsense server is a VM. Long story short once we had rolled out a new OPENvpn server and chosen Automated NAT rules the connection is working and as we wanted all traffic is being routed via the VPN tunnel :) Unknown adapter OpenVPN TAP-Windows6: Connection-specific DNS Suffix . : paacvpn Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-A3-2E-4B-10 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::419:140e:1684:a44b%17(Preferred) IPv4 Address. . . . . . . . . . . : 10.3.200.2(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : 15 January 2021 16:43:21 Lease Expires . . . . . . . . . . : 15 January 2022 16:43:21 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.3.200.254 DHCPv6 IAID . . . . . . . . . . . : 285278115 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-52-C3-D6-1C-1A-DF-B0-ED-33 DNS Servers . . . . . . . . . . . : 8.8.8.8 8.8.4.4 1.1.1.1 NetBIOS over Tcpip. . . . . . . . : Enabled C:\WINDOWS\system32>ping google.com Pinging google.com [216.58.198.174] with 32 bytes of data: Reply from 216.58.198.174: bytes=32 time=25ms TTL=117 Reply from 216.58.198.174: bytes=32 time=24ms TTL=117 Reply from 216.58.198.174: bytes=32 time=27ms TTL=117 Reply from 216.58.198.174: bytes=32 time=25ms TTL=117 Ping statistics for 216.58.198.174: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 24ms, Maximum = 27ms, Average = 25ms C:\WINDOWS\system32>tracert google.com Tracing route to google.com [216.58.198.174] over a maximum of 30 hops: 1 25 ms 24 ms 26 ms 10.3.200.1 2 22 ms * 24 ms 95.154.192.1 3 25 ms 23 ms 26 ms 109.169.17.190 4 25 ms 24 ms 22 ms po201.net2.north.dc5.as20860.net [84.22.173.154] 5 26 ms 24 ms 23 ms be256.asr02.dc5.as20860.net [130.180.203.7] 6 40 ms 25 ms 22 ms be256.asr01.ld5.as20860.net [130.180.202.46] 7 26 ms 25 ms 24 ms 72.14.219.214 8 24 ms 24 ms 24 ms 108.170.246.129 9 38 ms 34 ms 23 ms 108.170.232.97 10 25 ms 23 ms 25 ms lhr25s10-in-f14.1e100.net [216.58.198.174] Trace complete. So thanks for your patience in trying to guide me to a solution. All the best!