Just noticed that the NIC is not coming up as 100Mb/Full Duplex on our switch.  It is coming up as 100Mb/Half Duplex.  Both card and switch port are set to 100Mb/s.  When I moved it to a different port as a test and forgot to change the setting on the switch, when the port came up it showed 100MB/Half Duplex.  Messed around a little with the card settings, changed switches, same problem.  Swapped cards with the same model card and same problem.  So, I think I have identified the culprit. Card is an Intel Gigabit CT, which shows to be compatible with FreeBSD.  Intel has some info on their site regarding the card and FreeBSD.  If I find a solution with this card I will post the info here.

I always disable all that stuff without thinking about it.  Usually nothing good comes from them knowing you're behind a proxy.

Good luck waiting for this…

Good luck.

Theres a number of ways you can setup windows server, you have the dhcp/static ip clients being handled by pfsense or windows server.

You might find one is actually static for server hosting purposes like web & email, remote access/vpn etc, the other if in a different range is variable so you can surf the web with an element of privacy, at least thats what UK ISP's do anyway, but as I also discovered when ISP's hand out an IP block when ordering a single static ip, the ISP have in fact given all the ip's in the block. Whether your ISP have done this if its so large, only you can find out by setting up pfsense to accept incoming on the other ip's in that block, or they may have some other setup upstream to restrict you to one ip. Have a poke a round if interested in finding out.

I should have explained what you have explained to be clearer because like you say you dont need to bother with the back/return rule although I do agree with what you say, although have you created a chain to handle both TCP & UDP as one little trick for iptables? This probably best sums it up http://www.thegeekstuff.com/2011/01/iptables-fundamentals/ Tables -> Chains -> Rules. I quite like iptables for the ability to have the control all in one place, like you say with the state handling, the traffic shaping but I write my iptables differently to all the documentation I have seen online and in books which makes iptables much much easier to work with and understand imo. Both are different beasts in implementation though, and to be clear what do you mean exactly by the Alias in pfsense?

@stevenbrown8: I have a laptop at work which I plan to bring home Monday to test to see if its just the phone (iPhone 6 Plus) but I wanted to see if anyone else had the same problem before and what did they do to resolve this? Lots of variables at play, CPU speed is a factor, slower cpu's running different OS's will see a difference in download speed irrespective of it being a cabled, wifi or mesh network. For example an old windows pc can outperform on network speed newer versions of computers running linux as some network drivers for opensource are poorly written, cpu schedulers play a factor https://en.wikipedia.org/wiki/Scheduling_%28computing%29 as do some network cards link an Intel nic which can communicate direct with the cpu compared to say a usb nic. https://en.wikipedia.org/wiki/Network_scheduler

Here's recent the log file in case someone see's something I can't…. [image: Log_cap.png]

web content filtering (both http and https). It has been my challenge to get it "perfect" without affecting normal user behavior, I still have a long way to go :)

Use this…You can make a whitelist for the allowed subnet or users you want as well. https://doc.pfsense.org/index.php/Blocking_DNS_queries_to_external_resolvers

https://github.com/pfsense/pfsense/pull/1832

I solve this one,… seems that we cannot use regular login and pass acc. We need to use login as usual, and unique key from dyn.com which will authenticate it properly. So yeah, its fixed but its really strange. thanks :)=

@Derelict: States created by scheduled pass rules are automatically deleted when the rule expires.  States created due to the absence of a scheduled block rule are not deleted when the block rule schedule fires. So if you want to block access to port 80 except during the hours of 1800-2100 do this: Pass tcp source KID network dest any port 80 schedule 1800-2100 Reject tcp source KID network dest any port 80 no schedule. When 2100 comes around all the states created by that scheduled rule will be deleted, stopping current connections. New connections will no longer match the scheduled rule will fall through to the reject rule and will be rejected. Had the same issue with my daughter playing CoD/CS ! Thanks for the detailed explanation !

In my case the problem was with Nas4free which was built on FreeBSD 10.1 something at the time.  Not %100 of the version at the time I noticed it, but it was within the past month or so.

iperf

It shouldn't – but that still doesn't solve the problem here (cron spam). It's only relevant to arpwatch. Even if arpwatch supported some other mail mechanism, should we decide to include this script in base as sendmail or if some other package uses it the crontab spam would still occur. (Re)moving sendmail to alleviate cron spam doesn't fix anything, it only stops the notifications from letting the admin know that shit's broken. Fixing the broken shit is the cure.

Thanks for the link. The recommended video did provide links to more sophisticated scenarios, but none yet reflect my particular circumstances. It has however clarified the forum area that I need to post to (probably NAT), so thanks for that and regards to Dr Strangelove? ;)