2.1.5 RELEASE Now Available
-
How many hours got lost by this bug? Wouldn't it be easier to remove a "feature" nobody needs at that time (Gold button), until there is a solution not annoying a significant fraction of users?
Just a suggestion for improving corporate processes to meet user expectations…
-
I'm not going to whine too loudly because I'm sure the Devs are already working a fix.
-
I'm just glad that I no longer install pfSense updates immediately, and instead I wait until they have had at least a week or two to let the early-adopters and enthusiasts shake out the problems before I even think about putting it into production.
-
…same with me, I wait at least some days or try it on a back-up system first. The last 2-3 updates I did complete fresh installs on all systems running, as nano had its very special problems (wrong images, snort) in addition...
-
To those that were having issues, if you want to try the newest snapshot at https://snapshots.pfsense.org, I committed a fix for the top nav wrap.
https://forum.pfsense.org/index.php?topic=81165.msg443999#msg443999
-
I didn't have any problems anymore after an F5 (Firefox).
-
Is anyone having issues with OpenVPN clients "Unable to contact daemon"? If I restart it seems to go away for a few hours but then it happens again. The weird thing is that I believe all the traffic is still being directed through the vpn clients…
Version: 2.1.5-RELEASE (i386)
built on Mon Aug 25 07:44:26 EDT 2014EDIT: Include Log
Sep 10 13:00:25 openvpn[83477]: Exiting due to fatal error
Sep 10 13:00:25 openvpn[83477]: Cannot open TUN/TAP dev /dev/tun2: Device busy (errno=16)
Sep 10 13:00:25 openvpn[83477]: TUN/TAP device ovpnc2 exists previously, keep at program end
Sep 10 13:00:23 openvpn[83477]: [VPN PROVIDER] Peer Connection Initiated with [AF_INET] EDITED_OUT_IP#:PORT#
Sep 10 13:00:22 openvpn[83477]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Sep 10 13:00:22 openvpn[83477]: UDPv4 link remote: [AF_INET]EDITED_OUT_IP#:PORT#
Sep 10 13:00:22 openvpn[83477]: UDPv4 link local (bound): [AF_INET]EDITED_OUT_IP#
Sep 10 13:00:22 openvpn[83431]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Sep 10 13:00:22 openvpn[83431]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 10 13:00:22 openvpn[83431]: OpenVPN 2.3.3 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014
-
Yep, normally tunnel stays fully functional. Reboot resolves it, but may pop up again. No idea why…
-
I've only seen this when running it as a VM myself. Quite annoying and consistently reoccurs but only on my virtualized instances of pfsense.
-
Well I am happy to hear that I am not the only one but I agree that it is quite annoying. I am running bare metal so would seem to be something in the 2.1.5 release.
-
It started a couple updates back for me. It has had no impact on performance so I ignore it.
-
It started a couple updates back for me. It has had no impact on performance so I ignore it.
I have come to find that this does affect rules and port forwarding. I have a few website setup to use the my local ISP and not the VPN, however, when the VPN shows the arrow down, the website rules get messed up and for some reason is trying to send the traffic through the VPN (when the VPN is up then the rules function normally??) Also I have a script that checks to make sure my VPN's port is being forwarded correctly and if it detects that the VPN port has been closed it restarts the VPN to find a new open port. When the VPN is up then it functions as it should. When the VPN is down it thinks that the port is open when in fact the port is closed.
Has anyone found a solution to fix this issue? It is really starting to be a nuisance.
