@khodorb

That's a Github commit on the source code. From what I can tell, they added a piece of code to show these errors(the ones we are seeing now on our setups).

Since this piece of code wasn't there before, the errors weren't visible but now they are. In other words, we should have seen this errors before version 21.02 but we are only seeing them now.

I found the same link on the pfsense's redmine dating from 7 months ago, where Jim Pingle states the same.

@viragomann Yes, I know net30 is being deprecated by OpenVPN, not pfSense.
But otherwise thank you for clearing things up. I guess I'm stuck with net30 for now.

@khodorb said in Upgraded pfSense from 2.4.5 to 2.5.2 or 2.6.0 and OpenVPN no longer works:

https://blog.nuvotex.de/pfsense-crl-has-expired/

Thanks. I tried that patch and it was unsuccessful in fixing the issue. This was my post.

@jdavis0221 said in Setting up OpenVPN to access two LANs:

The 192.168.1.x network is just an internal network going back to the switch. The PLC network does not have internet access. Our WAN comes into the pf sense firewall, out to the 192.168.2.x LAN network which is also connected to the same switch that the 192.168.1.x LAN is on.

Two different L2 networks on an L2 switch?

What you wrote doesn't attest that the PLC uses a gateway. If not it cannot communicate with IPs outside of its own subnet. It's possible to access the hosts though from remote, but that needs an outbound NAT rule.
Additionally pfSense needs to have an IP in that subnet.

I changed all my S2S Server & Clients from:
Toplogy : NET30 --> Topology: Subnet
Remember to do it on the "Remote client first" , then on the "Server".

Since i already used a /30 as the Tunnel interface, this was all i had to do.

I experienced a brief OpenVPN outage, while the Server & Client restarted/reconnected ...
Outage 1..2 minutes.

/Bingo

@viragomann Thank you for your replay..

Let me check these setting and update you..

@pippin what is the certificate for?

I may have found the issue but only once I completely removed all of everything and started from scratch. The previous certificate was set for 10 years but the new version shows when setting up a certificate that it should be under 398 days. I've recreated it all from scratch (removed server, certificates, CA) and it's working now. The only problem is that I'll need to reinstall on all of the users since it's all new certificates.

Hi @gertjan

my client is Ubiqiti router, not Windows computer. I cannot change a version OpenVPN client in the router.

@viragomann
my friend thank you very much for everything, you solved all my problems so far, your explanation and patience was very important to me. Thank you very much

@nikim
If the OpenVPN server is listening on a CARP VIP (or an alias) that is expected.
If the primary goes down the services should start automatically. You can also test it by putting the primary into the CARP maintenance mode (Status > CARP).

@steveits

Since 2.5.x, this is advised :
allow-compression asym

It looks like compression will get depreciated.

For pfSense , the setting will be
a176bfab-06d6-45ae-b588-600d1446c788-image.png

@enesas
To narrow it down check out if the pushed DNS server is used and if you can resolve host names on the client.
Try a public name like google.com with nslookup or alike.

its hard to help you, there can be many things witch are wrong. without having a look into your router, its not possible for me to help you (maybe others)

I've had some success with using FRR on DCO, but I haven't tried it long term. The way the DCO interfaces are made they use kernel routing instead of OpenVPN internal routing. So the reason that overrides don't work with DCO also allows FRR to function, which depending on your use case, may be a great benefit instead of a drawback.

Thank you so much! That solution worked :)

@alfaro hey, i checked my iOS client settings and indeed, I couldn’t see the option anymore.

So I checked the iOS OpenVPN version history here:
iOS OpenVPN release notes and saw that they removed that option in the latest 3.3.0 release from July 19.
Second line: Removed the “force AES-CBC cipher” legacy compatibility option.

I am still connecting without any issues though.