Okay now I think I get it. The interface that the vlans are assigned to is able to connect to the trunk port on the switch by virtue of having the sames vlan numbers assigned to it as those configured on the switch. Is that what you are saying?

Thanks! Now I need to join github. :)

@AlphaSupreme: Although I limited the log size in the snort package, it had become over 40Gb in size. Deleted all the logs manually, rebooted, restored a config from yesterday, working. :) Going to keep an eye on my disk space from now on. Thnx for the help. could there be some way to keep an eye on such space via snmp ? syslog ?

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.