Possibly havent dont it myself, check out this link as you might need to log into the wifi login page from a computer  behind pfsense before you can get pfsense to connect properly. pfSense would have a wifi dongle/modem on its wan interface. https://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall pfsense can also do the dhcp if you wanted to go for this type of setup. ISP –- pfSense ---  switch ---- 10 clients

Do the servers respond properly from LAN when accessed via their LAN IP?  Can the servers talk out, such as fetching updates?  Everything in your config looks ok to me.  Perhaps do a capture on LAN just to confirm that the packets are getting out of pfSense or not.  Are you running any extra packages like Squid. Snort, pfBlocker…?  Anything in your firewall log at the time that you tested?  SSH in or login via console and view the pf NAT ruleset: pfctl -sn or the NAT & firewall rules: pfctl -sa Look for weirdness or post it here.

Seems to be working. Thanks!

Excellent, thank you Derelict! That's what I was thinking, just wanted to make sure. Turns out the primary is down due to the two Chelsio cards not being recognized (not populating in dmesg) - I have a separate post in the Hardware section for this. Thanks again!

Your device might not support vlan tagging so can you get your switch to tag the packets/frame as they come in and strip them as they go to the device?

2.2.5 is a maintenance release of 2.2 branch. 2.3 is a new release with a new gui & new freebsd base & new package system. just check out the 2.3 snapshots and you'll see the differences. (don't recommend it on any production systems just yet)

"Wow!! what a mess I had done." Said to say this is like 99.9% of the issues people have.. When in firewall rules are source ports given - almost NEVER!!  Most applications use a random source port, there are only a couple of exceptions - dns with zone transfers can use 53 as source and as dest.  Any is almost allows the source port.. Not paying attention to what port the service is actually listening on.. Glad you got it sorted.. Hope this thread helps the next guy..  Most threads could be like 2 posts.. Post up your rules and what your trying to do and could point out where the mistake was made..  It's almost always a MESS ;)  Not understanding how the rules are evaluated, top down.  Not understanding that you put rules on interface traffic will enter pfsense, etc.. Now what you should be doing is rethinking the whole idea of webgui open to the public net – I had mine open all of 10 seconds to get the screen shot.. And then OFF again to the public.  I admin pfsense and my network remotely via vpn access how any sane person would do it ;)

Nobody said it was worth anything other than the OP ;)  Pretty useless in feature set compared to pfsense for sure..  I was just remarking that its still being developed is all.. I highly doubt the OP went to the commercial version.. But sure maybe..

Update time So I had enough of this problem and because I got two older server cases from my company I made one of the cases run pfSense and replace it with my machine, my old one moved to the cafe. After moving the nic's and restored the backup everything is running fine. The system is now running 8 Days 22 Hours and all is good no problems at all. Thanks all for the response,

What reconfiguring did you do? I split it off into its own vlan as well but I'm still seeing the "unknowns" in igmp's log. Any tips?

@doktornotor: Omit the tunnel interface from the setup. IPv6 is not supported with "dig holes into your network" feature. If I'm following you (and the pull request you linked) correctly, the version of miniupnpd in 2.2.4 does not support UPnP or NAT-PMP for IPv6, and at the very least you would like the pfSense GUI to reflect this; is that accurate? @doktornotor: And - if your v4 WAN is RFC1918, this feature is totally useless for you. The WAN traffic would need to be allowed and forwarded on whatever is in front of your pfSense box, and LAN -> LAN never goes through the firewall. I fail to see how this feature is useless for me. The pfSense firewall is indeed running between HETUN6 and LANV6; if I have no rules, all packets to IPv6 LAN hosts are filtered, while manually adding rules for e.g. ICMP or TCP port 80 passes those packets as expected. My IPv4 edge router/firewall/NAT does not get in the way because pfSense is already tunnelled to the HE endpoint, and all IPv6 WAN traffic goes over that tunnel. Current state of affairs: I can manually create IPv4 firewall rules on my existing IPv4 edge router I can manually create IPv6 firewall rules on my pfSense instance Applications using UPnP can only create IPv4 rules on my edge router Desired state (although sounds like not possible without mucking around with different miniupnpd binaries): Manual rules same as above Applications using UPnP can create IPv4 rules on my edge router and IPv6 rules on my pfSense instance

Finally solved this problem - seems like the onboard NICs (Intel) had some fault or pathology. Disabled the onboard NICs, installed a four port Intel server card, and it's working fine now.

@Vampir1c: Hey everyone, this is been driving me nuts. I recently had to set up a new pfSense box when the other one died, I got the network up and running and all of the phones that were configured continue to work, unless you factory reset them. They become unprovisioned after that. I manually put the tftp server in the phones and it connects but then doesn't make a call. My guess is that they aren't pulling the configurations from the Freepbx/asterisk box we have. We have the freepbx box offsite. I've created SIP and RTP rules for the box as well as best as I could. I have the tftp server entered in the DHCP server too. For the life of me these phones aren't working. Anyone have any insight please. Thank you! I'm an idiot, spent hours doing a bunch of complex crap to find TFTP not enabled for LAN in System: Advanced: Firewall and NAT

Your PHP and modules don't match. Such as: PHP Warning:  PHP Startup: session: Unable to initialize module Module compiled with module API=20121212 PHP    compiled with module API=20100525 and you're on 2.2.0 (kernel at least, some world modifications were done), not 2.2.5, so moving thread. Upgrade to 2.2.4, and don't do any manual modifications to PHP or its files, and that problem will go away. If it's preventing you from being able to upgrade, reinstall 2.2.4 clean, and restore your config backup.

@cmb: Support for upgrades is something we'll get added for a future release. No specific target version in mind at this instant, but hopefully something we can have done for 2.3. Do you know if this is coming with the 2.3 release? Is there a existing bug number or shall I file a bug for tracking?

There are other tools that can do that.  Check the Traffic Monitoring forum for more information.