2.1.5 RELEASE Now Available
-
Cleared my cache and tried F5, still overlapping menue.
I'm on FF 31 and Win7.
But then I changed my default font size inside FF from Tahoma 16 to 14 and it works again !Just posting my experience. Tried it on 2 different pfsense systems, worked on both. YMMV.
-
Just updated to Pfsense 2.1.5 and I'm having the same issue with the HELP menu being too close to the SYSTEM menu (Overlapping) on Firefox and Chromium Ubuntu 12.04. Its really hard to Access anything in the SYSTEM menu I cant even logout.
After trying various fixes (F5, clear cache,etc) i realize it seems to be a Linux issue (i'm a fulltime Linux user) because after clearing the cache on my windows system the HELP menu moved to the far right. (see attachments)
Changing themes dont seem to work for me, only the "Pfsense" theme works and it sucks (i hate the layout on the left) i rather the drop down menus in the "Code-Red" theme.
Everything else seems to be working great so far, thanks for the great work you guys put into Pfsense hope you guys
can fix this in the near future.
![Screenshot from pfsense-menu 2014-09-03 08:45:38.png](/public/imported_attachments/1/Screenshot from pfsense-menu 2014-09-03 08:45:38.png)
![Screenshot from pfsense-menu 2014-09-03 08:45:38.png_thumb](/public/imported_attachments/1/Screenshot from pfsense-menu 2014-09-03 08:45:38.png_thumb) -
This has been covered so many times now in several threads across many sub-forums.
Either clear your cache, reload with Ctrl-F5, decrease your font or install the widescreen patch:
https://forum.pfsense.org/index.php?topic=81167.0
-
@jflsakfja:
Everybody that sees this on firefox, hit F5 (forget the cache, request the page again) on the page that you see it. It's simply a cache issue.
Cleared my cache and tried F5, still overlapping menue.
I'm on FF 31 and Win7.
But then I changed my default font size inside FF from Tahoma 16 to 14 and it works again !Just Changed my Font size to 14 and it Helps (Ubuntu 12.04), Thank you!
-
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.