-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.

@diablort666 said in OpenCPN: @viragomann La vpn se establece sin errores, si tengo habilitado el acceso remoto, haciendo pruebas no llego con ping a ningún equipo. Have to use a translater. See, what I wrote above. You can simply check that with pfSense, using the Ping tool in the Diagnostic menu. Do a ping to a computer with default options. I think, you will get responses. Then change the sourece to OpenVPN and try again. Do you still get a response?

@theskelly said in Client device running OpenVPN not connecting to LAN: so perhaps I'll make pfsense the client instead. Ttat's a very good decission.

If anyone else hits this, netgate support found I was using "openvpn" in the outbound NAT rules as the interface. Specifying this to the VPN Client interface resolved the issues.