Hi, You are aware that https://192.168.0.1:443 is a dirty. https implies (it that is enforteced now) that you should use the domaine mane (that points to the IP 192.168.0.1) and this domaine name should be declared in the certifcate that the GUI uses ….. Using an IP for https is ... well .... not good to start with. Example: my local domain is called "brit-hotel-fumel.net". My pfsense host anme is aclled "pfsense". I combined the two to pfsense.brit-hotel-fumel.net (and yes, I bought the domaine name brit-hotel-fumel.net on the Internet) so (example) startssl.com gave a a valid, signed and trused certificate. I installed the certificate on my pfsense and all is well. You can also use 'self made' certificates, you'll be seeing the message "can't trust that one" ones. Of course, using a certificate that dates from 2006 will never work Instruct pfSense to make a new one.

@dotdash: This complicates my SOP of typing random garbage. You and me both. I looked at changing it briefly, but that's not all that straight forward with the way password fields are handled. It probably ought to just generate something random on the back end, it was originally done that way so you could have a primary or secondary that was running on a stock BSD and switch CARP between them. But I don't think there is anyone who actually does that.

Simply take the patch mentioned in the redmine bug 4423 for offset, and apply the same idea to frequency: --- rrd.inc.old 2016-07-01 16:29:15.917333000 -0400 +++ rrd.inc    2016-07-01 16:23:52.048739000 -0400 @@ -912,7 +912,7 @@                                 $rrdcreate .= "DS:sjit:GAUGE:$ntpdvalid:0:1000 ";                                 $rrdcreate .= "DS:cjit:GAUGE:$ntpdvalid:0:1000 ";                                 $rrdcreate .= "DS:wander:GAUGE:$ntpdvalid:0:1000 "; -                              $rrdcreate .= "DS:freq:GAUGE:$ntpdvalid:0:1000 "; +                              $rrdcreate .= "DS:freq:GAUGE:$ntpdvalid:-1000:1000 ";                                 $rrdcreate .= "DS:disp:GAUGE:$ntpdvalid:0:1000 ";                                 $rrdcreate .= "RRA:MIN:0.5:1:1200 ";                                 $rrdcreate .= "RRA:MIN:0.5:5:720 "; Works for me; but as before you have to rm /var/db/rrd/ntpd.rrd and then recreate it (In services/ntp/settings, uncheck rrd logging, save, then check rrd logging, save). But, with typical negative frequency values, this will screw up the graph scaling terribly, so this is probably not the best solution with the current graphing back-end.

@cmb: Weird. Something's making it exhaust PHP's memory limit, which I've never heard of on that page. What does your existing port forward config look like? What's the system's config like in general? How many interfaces, Virtual IPs, etc. 16 Port Forwards total with two physical WAN links. Our main WAN has IP's 50.xx.xx.145-150 forwarded to specific machines inside our network running specific services accessible to the outside world. The secondary WAN is only using a single IP and has a total of 4 forwards to 3 different machines. Virtual IP's we have those same 50 addresses set up listed above plus one extra. Hardware specs are in the other post above. 50 or so OpenVPN connections and 3 IPSEC connections as well. Nothing too overly crazy and the hardware is overkill for what we're doing as of now. We never really have more than one person using the WebUI at a time and we're not using captive portal or really much else service-wise on PfSense either. Basically just a router and VPN server/endpoint.

What's in the DHCP log? That indeed is very busy dhcpd for a small network, more CPU usage than is typical on networks with thousands of devices with CPUs not much faster than what you have there.

@divsys: [Or just a keyboard and monitor [/quote] Oh, ehmm, right. Haven't used a physical keyboard/monitor on a pfSense for years, so  8)  old man and me…

That's done by default after 15 failed login attempts. That's not configurable. Still, you shouldn't leave the GUI (or any management interface of any sort on any device) open WAN-side, that's asking for trouble.

Are both proxmox servers on same cluster? If so, check that you are not using same vmbr and same ip´s for fw's interfaces.

Traffic Totals are coming back soon as a separate package. if you want more details as to why you can search or go through my post history.

Right.  Thanks. Maybe something like this would work: Keep that page and make it a link in the DNS Resolver page menu, like the access lists is (do the same for DNS Forwarder), and remove the overrides section at bottom of the pages.  Then the few who need access to the overrides without also having access to the main DNS Forwarder/Resolver page can use a shortcut in their favorites or on desktop, etc. This would provide the desired access control, retain consistency between resolver and forwarder,  without cluttering the main menu.

@johnpoz: "to identify which firewall I am working on." So you don't know what firewall is what based upon name, fqdn, IP? Couldn't you just use names like pf-sitename.domain.tld or pfsense.sitename.domain.tld, pfsense.sitedomain.tld, pfsense.othersitedomain.tld, etc.. or if just using IP would they be different IP? I like to apply different themes to the 3 pfsense boxes that I administer. Have you ever tried to compare 3 sets of ipsec settings across 3 different firewalls? It can get very confusing, and having a strong visual reference helps keep my head on straight. Sure, the address in the URL bar is a logical equivalent, but a different theme and image is more reliable when dealing with humans.

@Dawie_Kabouter: Does anyone know If there is a setting for the graph to update automatically? I constantly need to manually refresh the graph for it to update. This has been available since near the beginning of the monitoring graphs.  I've been using it all along. Status / monitoring auto updating #95 https://github.com/pfsense/FreeBSD-ports/pull/95 WARNING: This has not been "blessed" and is not supported.  Running it is on your own.

It can't be done easily and I think other features have a higher priority. Doesn't mean it won't ever happen, just will take some time to shake the code out to a point where it fits nicely.

Fixed, thanks!

It wasn't crashing anything, you were communicating with two diff devices and switching back and forth between them, which obviously isn't going to work right.

It is just that I started with NAT changes first and I noticed the X when disabled. After, I worked on Rules and was looking for the X change. When it did not changed to X I was under the wrong impression that it did not toggle properly. It is all good now.

Ticket #6464 is fixed and should show up in the next 2.3.2 snapshots if you happen to run those and want to test it out.