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

@viragomann I can access the destination when I use other OpenVPN client machines (including windows and android), so it is not a permissions things.

@pfsenseuser2020 Edit your OpenVPN server and scroll down to the Advanced Configuration section. You add reneg-sec 36000 to the Custom Options field.

@pfsenser_ca said in OpenVPN client fatal error: Our OpenVPN client is set to use "BSD cryptodev engine" currently This is definitely not a problem, at least I never met that (we have 100 - 120 OpenVPN clients- with BSD crypto) Try even these steps: NCP disabling (if it is checked) cipher change AES-256-GCM (GCM is faster and safer anyway, in principle) [image: 1610529442864-a2491c83-bc56-4fbe-86bc-87945afd831b-image.png]

@aperez said in Slow certificate-related pages: 200 certificates and 20 revoked certificates Yeah, that one is known. Admins start to become red if certs have to be revoked. This is just another reason. Glad you know why now.

If your trying to use ovpn file with openvpn on centos.. That is not the way you do it ;) So yeah your going to have problems.. Something like this would be more like it openvpn --config client.ovpn