After a whole day i'm able to run stunnel with openvpn. From a fesh install of Pf. Vpn, nat,rule give the vpn working fine. i don't set any dns. Dns leak , as it seem not possible to set DOH or dot in pfsense with just : providerdns.com/dns-query. the how: make sure Vpn is set to tcp 1194 and work fine before. So install stunnel package / then put: client mode check / listen ip : 127.0.0.1 /listen port: 1194 redirect to ip : vpnprovider.com / redirect to port: 443 log: notice / timeout : 0 / custom option: it,s exactly as your provider conf file. if they write option = noSslv2 , you put it all. If not it will just not work. The box custom option could be rename to : extra setting to be more clear. This is the first guide on internet. Also, passing from a first ovpn inudp1194 do work fine, no forward port or anything else. A bit slow to get the page load directly, but all fine, dual vpn back to back.

@cobrahead If it is a standard OpenVPN it will work on pfSense as well. But I don't know, what their desktop app really does. You may have to ask the providers support for details.

@stevemosher I'm on the verge of reverting too.. 2.5 is a shockingly bad release. Considering they had release candidates and still not fixed this.. I think the issue is around ciphers I have managed to 'fix' the fluctuating speeds by unchecking Enable Data Encryption Negotiation and changed the Fallback Data Encryption Algorithm to AES-128. I get lots of warnings in the logs but it connects and my speeds are now consistently back to how the were before my upgrade. How that's working or why, no idea but it seems to fix it for me so guessing from your comment even though it shouldn't affect it, it is for me. Let's see how much I can out up with it before I switch back to odler release

openvpn.txt Log kept getting flagged as spam, so it is attached.

-Edit 2: - Even though the tunnel is disabled in config, it can still be alive (don't ask) It even survives a service cycle. This is probably the reason the overlap existed in the 1st place...

@divsys Looks like that. But what is strange, since my post here I've set logging to my WAN rule to see incoming traffic to the OpenVPN port, yet for the 2 entries in the OpenVPN log I only see one matched entry in the firewall log. I would expect them both in the firewall log.

@zeeohsix And, if you got more rules underneath, make this rule @marvosa suggested.

@jknott thank you, that’s what I thought ! Wanted to clarify some stuff I read elsewhere ... BRgds/ Alan

@kiokoman Thank you for clarifying.

@divsys Ah ... My bad I might have missed that OP was using one server to serve multiple remote sites. I'm always using one server per remote site. /Bingo

@westlos said in Openvpn, port 993 not Connected: 993 Unless your isp is blocking that port - pfsense wouldn't care what port the vpn service is running on..

I'm on 2.5 (upgraded from working 2.4.5p1) I imported both their CA the client certificate and set Data Encryption Algorithms to: Encryption Algorithm: AES-256-CBC NCP Algorithms: AES-256-CBC The Fallback Data Encryption Algorithm to: AES-256-CBC Auth digest algorithm to: SHA1 (160-bit) Allow compression: Decompress incoming, do not compress outgoing (Asymmetric) Compression: Disable Compression [Omit Preference] Topology: net30 - Isolated /30 network per client Ping settings set to: Inactive: 0 Ping method: keepalive Interval: 15 Timeout: 120 Custom options: remote-cert-tls server; I do have my default gateway set to my ISP, and I and set rules for the packets I want routed via the tunnel. I also tag the packets and added a floating rule looking for those tagged packets in case the tunnel is down,and drop them, since vpn traffic I want out the tunnel only and never routed via default gateway.

Solution Found It was a MTU issue and most frustratingly it came to me at random. There was no particular reason to it other than me going, "Huh. I've never thought of MTU." and did some Googling to find the right MTU for OpenVPN and found that the default 1500 was too much for my network and had to step it down to around 1160 which fixed all the issues I've had before. I'm sure the routing quirk on the host was a one-off, but finally the VPN works just like how I want it. TL;DR: Check if the MTU is too high.

@bob-dig Sorry, my error, and sincere apologies. I now realise that I was actually examining the wrong server config file in /var/etc/openvpn/ - I now have three separate OpenVPN Servers. Please ignore the post.

On OpenVPN 2.5.0 you don't pick an encryption algorithm, you pick a list of Data Ecnryption Algorithms and set a Fallback Data Encryption Algorithm for when cipher negotiation doesn't work.

@jkring See example: https://forum.netgate.com/topic/155824/cisco-avpair-acl-from-radius-to-openvpn-on-2-5-0/2

Something is restarting it, but you'll need to check through the other logs (e.g. system log, gateway log) to see what is triggering that.