After some testing it seems the LCDProc package is causing this for me. When I do a webgui reset the display goes to a screen that shows Cli: 0  Scr: 0 with no backlight. I didn't notice it till days after my initial webgui reset. Once I restarted the LCD package the memory leak started again. Reset tonight and Im going to leave the package in the inop state for a few weeks. Running the dev package.

Sorry, I should have said I'm using the NAT method. Restarting the modem has fixed it, so I'm hoping it'll work from now on. Other than that, it was really easy to get this modem running with pfSense  :)

I was able to solve this by removing /var/db/pkg/perl-5.12.4 and then running the install again if anyone encounters this in the future.

The added NIC is a Intel  EXPI9301CTBLK.

let's put it this way. If you remove all the copyrights, you violate the license. If you build a binary and call it pfSense, you violate our trademark. Otherwise, yeah, perhaps you need an attorney.

The FiOS router currently handles NAT, but I am pretty unhappy with it's performance overall. It's prone to crashing and needed hard restarts, its throughput seems pretty poor, and the user interface is a pain. Hence my idea to essentially bridge it so that the pfSense box servers as the DHCP server and is the "first line of defense."

Well, that'd be because the latency between your demarc and gateway is above 20 ms. Not much more to it than that. Keep a ping going for a bit and watch the latency. If you're not seeing spikes in it, then it could be an RRD issue - but I highly doubt it.

errr shared folder watch?

possibly check your firewall rules as well.

Dude here is the thing - broadcasts do not pass segment boundaries. So either you got something setup as a bridge passing traffic, a dhcp relay example.  Or you have some cross over in your physical/virtual network that connects your networks to the same wire. It should be impossible for your 20.1 dhcp server to see broadcast packets from your 25.1 segment - so if 20.1 is seeing dhcp discover and sending offers then you got a issue with your physical network being connected. can you post up your esxi network setup?  Impossible to point out where your issue is without understanding your network - do you have vlans setup on your vswitches? In a normal setup it would be impossible for 20.1 to see broadcasts or dhcp discover from devices connected to your 25.1 segment - so you have something connected together that shouldn't be.

The rules between both OPT1 and LAN are to allow ALL between the two networks.  The LAN firewall allows all from OPT1 subnet, as long as the destination is in the LAN subnet. The OPT1 firewall allows all from LAN subnet, as long as the destination is in the OPT1 subnet. What you describe here in the first post is around the wrong way - if the rules were like that at first then they would not have worked. The way you describe doing it in the 2nd post is correct and works. That is why it works now and did not work at first.