You could try disabling and then re-enabling RRD backend graphing. Select 'Status/RRD Graphs' from the top menu. Select the 'Settings' tab then untick and re-tick the 'enables' option.

sorry went on holiday and busy. the issue was the first switch, it is a fast Ethernet, i switched the switches. I now have full gigabit on both wan and lan. thank you guys for putting up with my ignorance, I greatly appreciate you guys being fast on your responses and taking the time to help me out.

WAN should default to DHCP.  Is your DSL PPPoE or DHCP?  You might need to call your ISP for the details. Have them also tell you how to get your DSL modem in bridge mode so it's transparent and the pfSense WAN address picks up the outside IP address. Then you need to configure your WAN interface for either DHCP or PPPoE according to their instructions.

Does not make any sense whatsoever unless it's a managed switch with VLANs. Cannot even see how does that fix the "everytime we control internet access (giving internet access to specific IP, blocking websites etc.) we always call our ISP to perform the task" issue.

If you want to see the requests like that with URLs, you need Squid and its logging. Squid is essentially equivalent to TMG's logging of proxied traffic in that regard.

I've had good results with Snort.  pfSense also has Suricata.  Both are IDS engines (Intrusion Detection System) that load daily update files with threat parameters.

Hmmm I just tried again and it worked OK, not sure what I did wrong. Maybe I'll delete this thread.

If your topic "Want to Hire A Consultant" is right then have a look here: https://www.pfsense.org/get-support/#commercial-support

Indeed it not seems to work as I expected. What happens now is that both client groups only use the OpenDNS service that I provided along with my VPN provider's DNS. The DNS server of my VPN provider doesn't seem to be used for either connection - what could cause this? I have specified the OpenVPN tunnel as gateway and it is accessible. As I understand it, all DNS servers in the list are queried simultaneously (and using the gateway assigned to them) and the first (fastest) response is accepted. The strict-oder order option changes the behavior to do the queries subsequential. How about this: setting the strict-oder option, first DNS is my VPN provider's server (VPN tunnel as gateway) and the second DNS is OpenDNS using the WAN interface. The secondary DNS is neccessary to establish the tunnel as I do not know how reliable static IP's in the VPN config will work with this provider. What do you think about this  setup?

Are these HTTP or HTTPS sites?

I can't recall any circumstance where the interface and RRD stats on a stable release were inaccurate, those counters are pretty straight forward. Two completely diff means of calculating bandwidth, so if they match, you can pretty much be guaranteed that's reality. ISPs can measure bandwidth in a variety of ways. They may not count data to certain destinations (like things on their own network, especially if they have a IPTV/streaming video service or similar). You can run a packet capture on WAN, packet length 64 to minimize capture size over a longer period, count 0, all else at defaults. Start the capture, leave it running for a few hours, then go back and stop it. Download the resulting pcap, open in Wireshark, go to Statistics>Conversations and you'll see what you're actually passing on the wire (and what your ISP's passing you).

same issue I found many topic got no help

I'm going to answer the first question, and pretend I didn't see the second post. To restore selected parts of the config, you must backup selected parts of the config. e.g. Go to backup and change Backup Area from ALL to 'DHCP Server', then on the new box select Restore Area 'DHCP Server' and select your backup file.

Crap, I wish I knew this before I went ahead and bought the module I was working with… Either way. I'm not sure. Lately, I've been coming home to a down router that needs a reboot, so the issue is much worse... I'd like for someone with more experience to ask me for my logs so they can determine what the issue might be :(

I answered this for someone else here. If you have more questions related to Squid/SquidGuard, please post a new thread in the Packages forum.

@Derelict: I won't be able to take advantage of the Round Robin configuration. Condition 2 sounds like a problem to be solved on the web server.  Are you using name-based virtual hosting on it?  That breaks going to the server by IP address because the server has no idea what virtual host you're really trying to access.  Put a host override in the DNS forwarder pointing at the inside IP address of the web server and use the DNS name to access it.  If you do that you don't have to worry about NAT reflection. Thanks for weighing in. I can live with not doing Round Robin for the webserver. However, I have used DNS Forwarder that doesn't seem to work. The only I get this to work right now is by sending ALL TCP traffic from ANY source to ANY source (a rule set on LAN firewall rules). The moment I add destination in that rule as in IP of webserver things break because webserver requires DNS. I also, tried the DNS Forwarder and that failed for the same reason probably. In order to get to the bottom of this I think I should check into firewall logs but I am not sure where to start to what to look for. Once that is clear maybe I can change rules or decide to take a patch that gives me the ability to do Round Robin for ALL other traffic but port 80 TCP to the webserver. Any suggestions on where to find the necessary logs and what to look for?

Depends what you're trying to do… you have switch A, B, C and D are they all managed?  Which one is the netgear? Also what kind of LAGG are you doing.... link aggregation (LACP), failover, load balancing, etc?  If you're doing LACP (802.3ad), the switch has to support it and you usually have to bounce the LAGG at both ends to bring it up. Are you terminating your VLANs @ PFsense or on the switch?  If on PFsense, the connection to the Netgear will need to be a trunk. If you're terminating your VLANs on the Netgear, you'll need a separate untagged VLAN on the netgear connected to PFsense configured with an IP in the same subnet.