Your scanner is faulty, it is claiming vulnerabilities based solely on the version number. FreeBSD does not alter the version number when patching. Searching on that CVE ID combined with FreeBSD would show you it was patched a long time ago: https://www.freebsd.org/security/advisories/FreeBSD-SA-16:14.openssh.asc Comparing the FreeBSD version patch level on the SA with that on pfSense shows that the FreeBSD base of current versions is well after the correction date/version.

@KOM Many thanks =)

even with root user can't use ssh. The pfsense doesn't let me to login to the console even physically I couldn't login. it just show the ssh login prompt repeatedly. I don't know what should I do. Can I reset the root's password using rescue mode? Or is there any other easier way?

They have removed ALTQ though, in favor of pf queues. No telling when that might filter through to pf in FreeBSD since they have diverged significantly.

Install the cron package.

i am support this, i have a lot domains and sub domains, and use for iis10 , no good ways auto renew and bind these cert. lets cert time is so short.  :)

Are you running pfSense in transparent mode? Because your subnets are the same on both interfaces.

Very dangerous territory to play around in if you are not experienced and if you don't have a configuration backup, but you can fix the problem by hand-editing the config.xml file in /conf.  So before you do anything else, go to DIAGNOSTICS > BACKUP AND RESTORE and create a configuration backup. The pertinent section looks like this in the file: (note that yours will be different as you have different widgets enabled) <widgets><sequence>system_information:col1:open,interfaces:col1:open,log:col2:open,services_status:col2:open,nut_status:col2:open,snort_alerts:col2:open</sequence></widgets> The code deciphers as follows – you have the widget name followed by the column it resides in on the screen and then a value to indicate if the widget is "open" or "closed" (visible or hidden).  The fields for a given widget are delimited by colons, and the widget entries themselves are delimited by commas.  Fine the errant widgets, delete them from the <sequence>element key, and then save the edited file. Bill</sequence>

The boot sequence can't be made take advantage of parallel execution easily because there is very strict order in which certain things have to be initialized in because the boot sequence must accommodate many different boot methods and configurations. You might be able to run one or two part in parallel here and there but overall the sequence can not be altered.

@Gaurav202mehta: 24 hours power supply This means you need server mid-range proliant not an entry level. You need ProLiant DL20 or ML110 or similar that have TWO hot-swap PSUs, that you can change ONLINE and this means real "24 hours power supply" in combination with UPS and may be diesel generator (SDMO).

"Some DMZ implementations will forward ALL non-matched traffic to the DMZ target" What sort of garbage device would do that??  That would be just insane!!  Your talking some BS soho 20$ router with a dmz host function.. And then why in the would would said host then source nat that and send it back out?  That is just Batshit crazy talk ;)

where did you come up with that url? pkg is srv to files netgate.com http://files01.netgate.com/pfSense_v2_3_4_i386-core/All/pfSense-kernel-pfSense-2.3.4_1.txz https://files01.netgate.com/pfSense_v2_3_4_i386-core/All/ or could be files00.netgate.com ;; QUESTION SECTION: ;_http._tcp.pkg.pfsense.org.    IN      SRV ;; ANSWER SECTION: _http._tcp.pkg.pfsense.org. 3600 IN    SRV    10 10 80 files01.netgate.com. _http._tcp.pkg.pfsense.org. 3600 IN    SRV    10 10 80 files00.netgate.com. ;; QUESTION SECTION: ;_https._tcp.pkg.pfsense.org.  IN      SRV ;; ANSWER SECTION: _https._tcp.pkg.pfsense.org. 3600 IN    SRV    10 10 443 files00.netgate.com. _https._tcp.pkg.pfsense.org. 3600 IN    SRV    10 10 443 files01.netgate.com.