Pfsense 2.6.0 Buggy and Should have Remained in Development Branch (one bug report inside). Usage issues as well

Ryu945

Applying changes seems to take significantly longer. (Certain ones, I forgot which ones off the top of my head. I will probably edit this later to mention which ones.
Wireguard default gateway can be confused if you have multiple Gateways like WAN, OpenVPN1, Wireguard1. Wireguard will literally try to run through the OpenVPN1 gateway so Wireguard1 stops working when OpenVPN is turned off.
Applying configurations can fail. I was applying a DNS resolver setting when I got this.

https://imgur.com/zxB2GyM.png

Clicking save and apply again will not fix it. I had to alter the setting and then save and apply would work again. Then I could change them back to the desired settings. Then save and apply.

( I was told this is intended and not a bug) There is no way to disable OpenVPN clients. Disabling the interface does not allow you to disable the OpenVPN client. You have to delete the interface before you can disable it.
After you have disabled the OpenVPN client, you can then recreate the interface. Sometimes it puts this new interface on all your NAT Outbound rules you had for this interface originally and sometimes it doesn't so you have to manually add that interface back in for ever single NAT Outbound rule on that interface. This would not happen if you didn't have to delete the interface.

rcoleman-netgate

@ryu945 Have you opened any Redmines regarding your experiences? If so please provide the links.

https://redmine.pfsense.org/

Ryu945

@rcoleman-netgate Creating this as a bug report. I am placing these in one report since some of them are likely interrelated.

https://redmine.pfsense.org/issues/13363?next_issue_id=13362

marcosm

This can happen on pages that do DNS lookups. If DNS isn't working, the DNS queries neeed to time out before the page will load. This has improved significantly, but it can still be an issue. If you have specific examples and can reproduce it, please provide the steps.
The auto setting does an OK job in most cases, but the logic behind it is basic. It's best not to leave it as automatic if it can be avoided.
The error itself is not a bug, and that's not a directory that exists by default. It's saying it can't read the configured root.key file.
That's done on purpose to avoid actually buggy behavior :)
You can indeed go around the validation that way, but it's not guaranteed to work.

Ryu945

@marcosm

As I mentioned, there was strange behavior where even when you set the default gateway to Wireguard1, if the previous setting was OpenVPN1 then it will still run Wireguard1 through OpenVPN1. The gateway Wireguard1 will remain unusable until I set it to WAN. Then I am able to get Wireguard1 to not run through OpenVPN1 on either the WAN or Wireguard1 gateway.
Your saying the bug was not the error message but the fact that the files became unreadable until I changed the setting? The files became locked until I did that action which unlocked it.
It would make more since to implement this through disabling the interface. Deleting the interface should not be required. Why even have a disable interface button if you can't use it to turn off the OpenVPNs.

marcosm

The VPN interface is separate from, and unnecessary for, the VPN service to work.

Ryu945

@marcosm They are not totally separate. It is physically impossible to turn off the the VPN service in the OpenVPN area unless you delete the VPN interface in the interface area. I was told this was done to prevent unwanted behavior but I was suggesting that it be changed to where disabling the interface is all that is needed to be able to turn off the OpenVPN.