Relatively simple, probably not. If you're familiar with RRD and comfortable with the BSD command line,  this script might do it for you: http://oss.oetiker.ch/rrdtool/pub/contrib/merge-rrd.txt merge-rrd.tgz  http://oss.oetiker.ch/rrdtool/pub/contrib/ https://www.google.com/search?q=pfsense+merge-rrd Most people just toss the old data.

First thing to check is Status: System logs: Firewall to see if the traffic is being blocked. That said  ;), I think your floating rule is being applied to OPT1 and LAN interfaces (the members), but when you set net.link.bridge.pfil_bridge=1 and net.link.bridge.pfil_member=0 you're telling the firewall to filter the bridge, not the interfaces. So the floating rule isn't matching.  (f you invert your net.link.bridge.pfil_ settings, it might work) Or… The recommended procedure for version 2.x is to assign the bridge as an interface and assign the IP address to the new Bridge Interface. See this post for the summary: https://forum.pfsense.org/index.php?topic=38042.msg196370#msg196370 @GruensFroeschli: 1: Interfaces –> assign --> bridges. 2: Create a bridge and add all interfaces you want as member. 3: Interfaces --> assign 4: Assign the bridge you just created. The bridge is treated like a normal interface. Configure IP's on this interface (5:) Assign the interfaces which are member of the bridge. Set their IPs as "none". (6:) Create firewall rules on the member-interfaces of the bridge to allow traffic. More detail: https://forum.pfsense.org/index.php?topic=20917.0 That said (again)  ;), I used the book. It's got an entire chapter devoted to bridging.

Yes, but not nearly as pretty or concise. For allowed packets and current connections go to Diagnostics: States, enter the IP address, click filter. (To update, click filter again.) You can also get real time state monitoring at Diagnostics: pfTop. To see blocked packets go to Status: System Logs: Firewall, enter the IP, click filter. To update, click filter again. (To see which rule caused the block, click on the white/red X at the far left.)

If anyone could give me an idea, I'd be very grateful  :)

Just noticed this thread got some more replies. One doesn't really have anything to do with the other.  Just because you are using the DNS forwarder doesn't necessarily mean that you don't also have a good reason for allowing some machines to use external DNS. I made the assumption it did because pfsense does a lot of things automatically; many rules are implicit. A warning such as I suggest is just a warning; it wouldn't harm people who did not make the assumption, and it would help those who did (not to mention, those who have to straighten the latter out…)

4.1 is quite old, an issue perhaps? I don't run ESXi though I can't really comment. Steve

That's just how it works I FreeBSD. I have a similar 'parent' inerface shown in ifconfig. The ath driver/hardware can support multiple virtual access points and each is represented by a different interface. In pfSense the interfaces are named athX_wlanX which makes it easier to read IMHO. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html Steve

Thanks MindfulCoyote. You are correct. I am going to create a subnet specific for developers, and bypass the proxy altogether for them. Its the "least worst" solution on this occasion, but we lose the ability to track their behaviour which is a shame.

That did the trick, thank you.

Thanks chemlud I'll probably try that next.

@jimp: other than by looking at the source and patches to see their meaning by the context in which they're used. Thanks jimp. That was actually where I went first… but the source is harder to see nowadays than most. I'm slowly grinding  my way through the super secret authorization source code access process.  ;)

Did you look at the details of the certificate to see how it was generated and dated? The GUI certificate is self-signed so it would not show as revoked.

I experienced this today across 3 complete re-installs using the following setup: mBUFF filled to 99% and stopped working or outright crashed Physical Server Hardware (ESXi Host): HP DL360 G4p 12GB RAM Dual 72Gb U320 drives in RAID 0+1 2 tgz3 NICs onboard the server 2 INTEL Dual GB 82546GB NICs installed - (bringing total interfaces to 6.) ESXi Host : 4.1.0 u1 (fully patched) - BUILD: 1682698 Guest OS Configuration for PFsense 2.1.4 i386: PF NIC:                    ESXi NIC: 0: WAN1  DHCP  –------->  ESXi_NIC1 1: LAN  192.168.1.1  -->  ESXi_NIC2 2: WAP  192.168.2.1  -->  ESXi_NIC3 3: DMZ  192.168.3.1  -->  ESXi_NIC4 4: WAN2  PPPoE  -------->  ESXi_NIC5 5: LAN  192.168.5.1  -->  ESXi_NIC6 6: PFL  192.168.6.1  -->  ESXi_BLIND_SWITCH (PFlink to other PFsense FW VM on SAME ESXi host) Using official VMware Tools drivers and install. (NOT Open Vmware Tools Driver Package) This guest OS continuously has driver issues or something because i cannot keep the guest running correctly. I lose network connectivity constantly and/or the PFsense firewall hangs.

That's true. But software authors and configs do have the possibility to cache some items but not others, or cache them one way and not another. So perhaps I should have been more specific: Do any of the current caching packages allow selective caching of URL content according to a rule (ie URL matches this domain/mask/regex then cache, otherwise don't)? Or are they all, "all or nothing"? Do any of the current antivirus/antimalware scanner packages allow scanning either without caching, or using a RAM based (rather than disk based) scanning mode or caching mode, or using a ramdisk for the disk based cache? That's probably what I should have asked…

@MindfulCoyote: @elementalwindx: Ok so it ended up that I was trying to do the impossible. Trying to get 2 virtual adapters to use 2 different VLANs. So I simply added a 3rd gigabit nic I had laying around (7 total now) and I simply put vlan 6 in that enable vlan id in the hyper-v and configured the proper firewall rules, and everything started working perfectly. Added blocking rules to separate the networks and its working perfectly :) Those are very interesting findings. I've seen other issues caused by hypervisor's network implementations. It's seems that virtual pfSense instances definitely face obstacles that bare metal does not. @elementalwindx: Ok well I took pfsense out of the equation and put a dd-wrt router in place of it. Just curious, when you when you swapped in dd-wrt, was it also virtual or bare metal? It was bare metal off a netgear router I had. I'm now having issues of my pfsense 2.2 alpha pushing it's own ssl cert onto my exchange clients. :/ . Wish I could figure out how to stop that.

This page may help you: https://doc.pfsense.org/index.php/Known_Working_3G-4G_Modems As for how pfSense works with them, I have no idea.

Yeah well…!!! I have posted it as a bounty... but so far no one has answered.... I´ll be a little bit more patient... Your advice about the script helped... at least now I have a better idea on how to do it... I already got the ups...  So I´ll wait for the bouty to be taken>>> and in the mean time I'll continue to learn how to code... Thank you for your attention and time!!!  ;D ... Link to the bounty !!! https://forum.pfsense.org/index.php?topic=78832.0

This is just quick test setup I put together with minimal configuration, to reproduce the problem in the simplest way. The actual setup is an usual single WAN pfSense box.

If your default action in Common ACL is Deny then there is no web access.  Hard to tell what you did without seeing some screens.