That seemed like a good idea at the time, but now I'm wondering. Yeah it's spewing stuff that's not necessarily helpful, sure it should be fixed, but might end up going back and silencing that.

Thanks for the pull request to fix at least some of that, I merged it.

Shouldn't be any functional difference in LACP from earlier versions to current versions. Where LACP works switch-side, it works the same on both. There must be some difference there, but from the sounds of it, LACP doesn't work properly in general on your switch.

FEC should be fine though. That's just an alias for roundrobin.

Great CMB, thank you; I switched to hybrid, deleted the existing rules, and hoppa, it's working again  ;D

Thank you for this ultra-fast help  :)

It's all fixed on the Thu Jan 08 03:14:18 build. Thank you.

Yeah the important is that the tunnels works.
Yesterday there were some fixes done for functionality.

Hopefully today everything related to dashboard etc will be fixed aswell.

?

To my knowledge, I'm not associated with Windstream or an MPLS network.

I upgraded your system to the version with that fix in place, overwriting the workaround that was in place previously, and it still looks good. Pretty sure this one's knocked out, and it probably caused some others' weird, hard to debug issues.

my 2 isps share backbone which is mpls sometimes apinger zero's or close to it at same time. i have choosen 8.8.8.8 for one and 8.8.4.4 for the other monitor possible google could have mad some change when this all started too

Glad to hear. Tunnels never come up unless there is traffic triggering them, or you have the "Automatically ping host" set in the P2, so sounds like that's the expected end result.

Its a freshly installed win7 machine, as I found a way to install software & updates that bypass linux authentication (sudo) the other day which is not good, but it ironically wants me to authenticate to uninstall the same software.

I'm embarassed to say I didnt try compatibility mode as I didnt download the updates for it, but a quick check toggling that shows it works and logs in fine, although I normally use FF.

This seems to be fixed on latest versions thank you for reporting.

@dotdash : ok, thanks for your comments, I am running it now that way (with the other UDP port getting a 10.6.x.y) gateway and it seems it's working without any flaws. It can only be a /16 mask from the provider because the problems occured with GW1 having 10.4.A.B and GW2 having 10.4.C.D so it has to be a /16 mask otherwise with a /24 mask there wouldn't have been these conflicts.

@cmb : No I didn't add the gateways for the VPN clients on my own, but I somehow "renamed" the automatic ones (through adding a gateway based on the automatic created gateway (+ button on the gateway), entered an alternative monitor IP and shortened the name, then saving) -> they then had a shorter name and the "automatic" ones disappeared automatically.  But I don't see a mistake in doing it like this because I did that from the beginning on and it's working without any flaws. I did the copying workaround because you can't rename the automatic created ones.

So I removed the BUG from headline, thanks!

Yeah that works too.

I added all these to the wiki:
https://doc.pfsense.org/index.php/Disable_Sounds/Beeps

I got my WiFi issue fixed.  I did some reading about key rotation and several message boards indicate that the key rotation should be set to 0 (which pfSense doesnt support) for straming A/V. When the keys rotate the connection will temporarily drop when in the process of rotating which is unacceptable for streaming A/V.  If it is set to something above 0 then it needs to bet set to at interval of at least 5 minutes because when the keys rotate devices are able to negotiate the new keys once per minute up to 4 attempts, which means no less than 5 minutes.  Changing the default value of key rotation from 60 to 300 solved the issue. Unless my research is wrong then Id suggest the default value in pfSense be changed from 60 to 300.

The lease length is set to the default of 7200 sec. I cleared the logs and all is quiet for now. I don't see it flapping yet. I'll check tomorrow and see what happened.

@jimp:

While that may be technically possible, it's still not feasible. There is not much to be gained by that method either. What specifically are you trying to accomplish? Using that method is not always better than using other security practices.

If you are worried about someone hacking the firewall, don't run services on the firewall and don't let anyone else have access to manage the firewall. Run the services on other servers than can be locked down tighter in that manner.

Absolutely, agree on minimizing services on the FW- least privilege is a good thing. I am just trying to lock down the FW like our existing FreeBSD servers.

I'll try and work on a hardening guide in my copious spare time (unless one exists already).

Message = "Select Server User Authentication mode to be used if you require authentication backend."

It was trying to match "Local Database" from the config to the Turkish translation "Yerel Veritabani" , with no success!
The code was not correctly distinguishing between the fixed strings stored in the config - "Local Database" etc - and the translated text displayed on the GUI - "Local Database" or "Yerel Veritabani" or…

Fixed by: https://github.com/pfsense/pfsense/pull/1422
Bug report: https://redmine.pfsense.org/issues/4180

Please do some testing of other places that have:
a) A drop-down list of values that are translated
b) A multi-selection box that has translated text
c) Other places where the valid input data is translated to the GUI language

All those sort of things could have validation issues - because when in English the values stored in the config and text displayed on the GUI are the same, so we do not notice the bugs in English!

It does work, as expected …  ;). FYI, I tested using the patch (though it says I can't revert it for some reason, but that's no biggue).

Works great actually - both the pull-down, and the email. Thanks!!!

Noticed it started happening again… check_reload_status continually.  Resetting the gateway made no difference, and there is no noticeable loss of connectivity ever nor any packet loss reported.  Anybody else?