So…what's the verdict on 2.3?
-
I am having several issues and will be rolling back to the last version. I love the new lay out. But, I have had several crash reports in the last few days. Never had an issue with the last version. But, 2.3 looks promising. I'm relitvly new to pfSense about 8 months now. Haven't had any problems until now. I'm guessing a few tweaks here and there and 2.3.1 will be just fine.
-
For me I can not get Squid to work and with out squid squidguard is also down I have read all the posts double and triple checked the settings removed rebooted and reinstalled them try a dozen different command prompts people have recommended with no luck I am slammed at work so I am going to leave it for now and probably work on it on a Sunday so if I make an error the whole office isnt offline
I am in the same boat with you on this one. I've tried everything I can think of. When I turn transparent proxy off and have network connection setup to use the proxy manually everything works great. Once I use transparent proxy only SSL sites work. And of course that is bc they bypass the proxy. I am on 3 different lan interfaces and I haven't tried the "main" one. It does say in ACL "The proxy interface subnet is already an allowed subnet. All the other subnets won't be able to use the proxy." Which confuses me greatly. Waiting to see what the deal is with that.
EDIT: Ok I got off my lazy butt and checked the computers on the other subnets/interfaces. The transparent proxy works fine on one of the 3 nic/subnets but not the others.
-
Seems to work fine. Absolutely HATE the new theme and hope someone will make the old one an option again.
That won't happen. Bootstrap is not just a new theme, but a significant change in the way the user interface is implemented. The old user interface will not reappear in pfSense 2.3 onwards as the code implementing it does not exist in 2.3. Further, you cannot graft the 2.2 UI onto the 2.3 back end, as there have been so many changes in the back end.
The new UI is something of a shock to the system if you are not used to it, but it is worth persevering with. It has many advantages, such as being easier to use on a mobile browser.
-
Well, at least the color-theme of the old interface would be nice to be back - this all-white and all-black are the two extremes. The old one was much more human-friendly - I'm talking about the colors here.
-
So far I've experienced 4 issues. 2 of which have been resolved.
Symptom: DPinger wouldn't start.
Cause: Incompatible gateway monitoring parameters brought forward from 2.2.6.
Solution: Adjust the gateway monitoring parameters to be compatible.
Forum Thread: https://forum.pfsense.org/index.php?topic=109712.msg610813Symptom: Slow to boot, initial sluggishness, notifications of aliases not available when loading firewall rules.
Cause: URL table aliases not backed up / restored with RAM Disk enabled.
Solution: Patch code to backup URL alias tables with RAM Disk enabled.
Bug Report: https://redmine.pfsense.org/issues/6189
GitHub Pull request: https://github.com/pfsense/pfsense/pull/2878Symptom: Notification with missing 'LAN address' when loading firewall rules during boot up.
Cause: TBD. Thought to be a race condition.
Solution: TBD
Workaround: Created an alias with the LAN interface IP address to use in the rules instead.
Bug Report: https://redmine.pfsense.org/issues/6133Symptom: 1st OpenVPN instance reported as stopped/not running and can't be started. But 'ps uxawww' shows it as running with different pid than is in the pid file.
Cause: TBD. Thought to be a race condition.
Solution: TBD.
Workaround: Either reboot or kill the process and then restart the OpenVPN instance.
Bug Report: https://redmine.pfsense.org/issues/61322.3-RELEASE (i386)
built on Mon Apr 11 18:12:06 CDT 2016
FreeBSD 10.3-RELEASEIntel(R) Pentium(R) 4 CPU 2.66GHz
-
@/dev/null:
I have never has so much grief from a network device
I have tossed my m1n1 in the trash
-
the checksum was bad on the site so my update failed with 'can't verify image'.
-
the serial port works then doesn't, and does.
-
then for some reason I had to reboot the device several time for it to get the full 2.3 nanoBDS image just to load.
-
after I get the image to load i find the UI barely fastest enough to use.
-
come back 10 hours later to find that the WAN port went down UI is completely unresponsive. gateway timeout issues just trying to load the login page.
-
can not get the serial port to work at all anymore.
having to reboot every other day.
Not to discount your issues but from all your information provided sounds like your box was giving up the ghost. And way underpowered to even consider this upgrade.
I did my first 6 boxes (of all different types of equipment) without so much as a hiccup. 7th box had drive errors new drive cause the boss is cheap … 8th got scheduled replacement...
-
-
@/dev/null:
I have never has so much grief from a network device
I have tossed my m1n1 in the trash
With respect, where was your reversion strategy? All you needed to do was install 2.3 on a different card, then restore a copy of your configuration file. If 2.3 failed, you merely had to pull the 2.3 card and reinsert your 2.2.x card to return to normal operation.
It would be good to know your hardware specification but, as chpalmer has said, it sounds like you were using underpowered hardware that might also have been showing hardware problems and/or compatibility issues with FreeBSD 10.3. pfSense 2.3-RELEASE is not some random untested junk that has been hastily cobbled together and shipped - it's undergone lengthy development and testing. As with all major upgrades, the magnitude of the changes and the impossibility of testing the code in all possible environments has shaken out some regressions, but 2.3.1 will be along within a few weeks to mop up many of those problems.
I'm not surprised your attempt to get free telephone support was knocked back. Commercial support is on a pay per incident basis. The developers are working flat out dealing with issues thrown up by the 2.3 release and with incidents submitted by paying customers. In any event, the answer to such profound issues with unsupported hardware was almost certain to be 'try new/different hardware, or post on the forums to see if the community can help'.
The hardware requirements gradually creep upwards release by release. Most of the development is now done on amd64, which is the recommended version for all 64 bit capable hardware. i386 support will eventually disappear. Inevitably, therefore, amd64 is better tested than i386 these days.
NanoBSD support will also disappear in time, as it is not needed for modern embedded hardware.
Not to discount your issues but from all your information provided sounds like your box was giving up the ghost. And way underpowered to even consider this upgrade.
I did my first 6 boxes (of all different types of equipment) without so much as a hiccup. 7th box had drive errors new drive cause the boss is cheap … 8th got scheduled replacement...
I agree with your analysis and note my experience is similar. Having noted the contents of the release notes, I had no problems upgrading a production firewall to 2.3. I did have a reversion plan to go back to 2.2.6 if I encountered insurmountable problems with 2.3.
-
For most, it has been fine. There are some issues we have fixed post-release, and there are bound to be more. We intend to have a 2.3.1 out before the end of the month to address what we've had to far.
If you did have an issue on 2.3 and it has not already been reported, it would be best to attempt the upgrade again and gather as much detail as possible. If it is a new issue and nobody else hits it, the odds of it being fixed are low if we can't reproduce it and have no supporting information.
I think my first 2.3 upgrade exposed deficiencies in my setup more than anything else.
My current 2.3 on an expendable box seems stable enough.
I have to agree with others though that the ui is lacking.
It's the old problem of developers developing.
They don't require repeated attempts at creating a firewall rule - at least not like I often do.
y
The mod/apply/test cycle with the new ui requires a lot more steps.Is there a toggle somewhere I missed to add the Clear and Filter buttons back to more or less where they were?
With the Rule as a column, and entries limited to 20, it wasn't too bad to keep refreshing as you made changes.
The new layout is kind of awkward.
Even if that's entirely my own deficiency, it will keep 2.3 on the back burner for me for a while.
I'm not sure if the change to the way var usage is displayed would have save me from myself earlier.
The real problem for me in 2.2.6 was that I wasn't paying attention - and 3.4mb is NOT enough for /var/run when a crash dump lands there.
I didn't notice it right away, as it had never been an issue, but when php-fpm crashed and filled /var/run, it caused me to hit Google, and without understanding the ramifications, I quickly jumped into the ui to set temp and var to what I though was a generous 512MB.
Given that I use squid at that site, 512MB isn't nearly enough, though I suppose I can buy a little time by dialing the cache back.
Guess I'd best jump on that, as the customers will be hitting it hard in two hours.
Is there a non destructive way to move var back to the hd?
For some reason, I had issues when I stopped by there to due a quick reinstall last night.
Not pf related - I think the pos system was acting as a rogue dhcp server, which really screwed things up due to the vlans.
Need to remember to take that offline next time.
-
I started the upgrade to 2.3 from the firmware upgrade menu in the web UI. After the reboot it hangs nothing happens I started TOP in the CLI to see if there was still some activity but nothing. I waited like 90 minutes but it did not come up. I figured I can wait til tomorrow or I try another restart, with the same result it hangs on boot.
I rolled back to 2.2.6 and thats what I will be running for now. Maybe in a few months I try again.
-
They don't require repeated attempts at creating a firewall rule - at least not like I often do.
The mod/apply/test cycle with the new ui requires a lot more steps.How so?
Is there a toggle somewhere I missed to add the Clear and Filter buttons back to more or less where they were?
With the Rule as a column, and entries limited to 20, it wasn't too bad to keep refreshing as you made changes.
The new layout is kind of awkward.
To which screen specifically? The logs? System > General Setup, check "Log Filter" and "Manage Log" and it will show the panels on the page. Though if you only want to see if traffic is hitting a rule, just look at the hit counters on the firewall rule list now.
I'm not sure if the change to the way var usage is displayed would have save me from myself earlier.
The real problem for me in 2.2.6 was that I wasn't paying attention - and 3.4mb is NOT enough for /var/run when a crash dump lands there.
The disk usage display for /var/run has been the same since 2.2.x. It's random that the php core ended up there, it doesn't always land there if it crashes.
Given that I use squid at that site, 512MB isn't nearly enough, though I suppose I can buy a little time by dialing the cache back.
On a full install /var/run is a tiny RAM disk that only holds PID files and some other small flag files, it doesn't contain data. The squid cache is in /var, which is typically a part of / unless you have done a custom install or activated the option for /var in RAM.
Is there a non destructive way to move var back to the hd?
See above, /var/run/ is not all of /var/ – If you did activate /var in RAM, it's under System > Advanced, Miscellaneous, and would not have changed automatically.
-
pfsense team. Thanks for all your hard work.
While I ran to minor issues, I am very pleased with the end product. the UI its amazing and the dark theme just rocks.
Keep up the good work. -
Well, at least the color-theme of the old interface would be nice to be back - this all-white and all-black are the two extremes. The old one was much more human-friendly - I'm talking about the colors here.
I think the main issue with the new GUI for many people is the color scheme - dark gray text on a light gray background is just a poor design and the vertical white space probably does help on the mobile view but it's not good on a large monitor. I'm sure that all this will get sorted out eventually.
FYI - I'm finding that playing with the monitor brightness and contrast controls does help.
-
Well, at least the color-theme of the old interface would be nice to be back - this all-white and all-black are the two extremes. The old one was much more human-friendly - I'm talking about the colors here.
I think the main issue with the new GUI for many people is the color scheme - dark gray text on a light gray background is just a poor design and the vertical white space probably does help on the mobile view but it's not good on a large monitor. I'm sure that all this will get sorted out eventually.
FYI - I'm finding that playing with the monitor brightness and contrast controls does help.
System > General Setup, change to the Dark theme. Some people much prefer that, I find it difficult to read in most cases, whereas the light theme reads perfectly for me.
Anyone is free to make new CSS themes, it's pretty easy to do now.
-
I am having several issues and will be rolling back to the last version. I love the new lay out. But, I have had several crash reports in the last few days. Never had an issue with the last version. But, 2.3 looks promising. I'm relitvly new to pfSense about 8 months now. Haven't had any problems until now. I'm guessing a few tweaks here and there and 2.3.1 will be just fine.
I too have had several crash reports since the upgrade, and did not have any with the previous versions. They don't seem to affect functionality and don't cause a reboot.
I have had an issue with Gateway monitoring indicating that one of my gateways was down, even though I could ping the gateway uses pfSenses ping and from a workstation. Workaround was to disable Hardware Checksum Offload. However, I try the payload size fix. I had tried editing and re-saving the Gateway before.
Also had this https://forum.pfsense.org/index.php?topic=110438.0
No issue with Squid
Had a notification re an alias. But this was resolved after editing the alias and the relevant rules.
Otherwise seems to be pretty good
-
They don't require repeated attempts at creating a firewall rule - at least not like I often do.
The mod/apply/test cycle with the new ui requires a lot more steps.How so?
Is there a toggle somewhere I missed to add the Clear and Filter buttons back to more or less where they were?
With the Rule as a column, and entries limited to 20, it wasn't too bad to keep refreshing as you made changes.
The new layout is kind of awkward.
To which screen specifically? The logs? System > General Setup, check "Log Filter" and "Manage Log" and it will show the panels on the page. Though if you only want to see if traffic is hitting a rule, just look at the hit counters on the firewall rule list now.
I'm not sure if the change to the way var usage is displayed would have save me from myself earlier.
The real problem for me in 2.2.6 was that I wasn't paying attention - and 3.4mb is NOT enough for /var/run when a crash dump lands there.
The disk usage display for /var/run has been the same since 2.2.x. It's random that the php core ended up there, it doesn't always land there if it crashes.
Given that I use squid at that site, 512MB isn't nearly enough, though I suppose I can buy a little time by dialing the cache back.
On a full install /var/run is a tiny RAM disk that only holds PID files and some other small flag files, it doesn't contain data. The squid cache is in /var, which is typically a part of / unless you have done a custom install or activated the option for /var in RAM.
Is there a non destructive way to move var back to the hd?
See above, /var/run/ is not all of /var/ – If you did activate /var in RAM, it's under System > Advanced, Miscellaneous, and would not have changed automatically.
No - I get that - now - I just jumped the gun and set /var to a ram drive because I misread the screens and was in a hurry.
Now I have to blow it out again because I was also in a hurry on the reinstall - reset to factory defaults didn't seem to clear the whole config
-
Thought I've never had issues with the updates in the past, this one has been nothing but problems. Random hardware lockups, pfBlockNG crashes, etc. (See pfBlockerNg issue here https://forum.pfsense.org/index.php?topic=110458.0)
-
Thought I've never had issues with the updates in the past, this one has been nothing but problems. Random hardware lockups, pfBlockNG crashes, etc. (See pfBlockerNg issue here https://forum.pfsense.org/index.php?topic=110458.0)
If you submit that crash to the devs for pfBlockerNG, I may not see it… If you have any future pfBlockerNG errors, send me a PM with that error...
I see the issue with the De-Install script, and plan on submitting a Pull request today to fix that...
-
I've noticed the cron's for Snort are also not removed with the package.
-
I've noticed the cron's for Snort are also not removed with the package.
I will check into this. I am working on another Snort problem right now and can incorporate any needed fix into the upcoming release. The package makes system calls to remove cron tasks, but that process may have changed under Bootstrap. The entire package install/uninstall process got changed with the move to pkg and away from the old XMLRPC stuff. Just a guess since I have not investigated yet, but it could be some of the uninstall triggers us package maintainers formerly depended upon may not be happening the same as they used to.
Bill
-
I've manually removed the packages, cron, and anything I can find from the pfSense config file and am going to see if that solves my problems. Is there anything I can do to remove any files that might be lingering from Snort of pfBlockerNG? I plan to try to reinstall the packages at some point but want to ensure everything is re-installed.
