Yeah on your dhcp server tab Deny unknown clients If this is checked, only the clients defined below will get DHCP leases from this server. Enable Static ARP entries   Note: This option persists even if DHCP server is disabled. Only the machines listed below will be able to communicate with the firewall on this NIC.

What are you saying is broken? [2.2.4-RELEASE][root@pfSense.local.lan]/root: php -v PHP 5.5.27 (cgi-fcgi) (built: Jul 13 2015 19:15:15) Copyright 1997-2015 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies     with Suhosin v0.9.37.1, Copyright (c) 2007-2014, by SektionEins GmbH [2.2.4-RELEASE][root@pfSense.local.lan]/root: /usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "test.test&depth=2&certdepth=1&certsubject=C=US,"; echo; echo $? OK 0 [2.2.4-RELEASE][root@pfSense.local.lan]/root:

@doktornotor: Yeah, 192.168.10.200 won't ever work as destination in WAN rules. It's not routable. Try NAT instead. And post screenshots. Not this ASCII art. i want to implement internet speed  control on whatsapp upload/download both for every single devices which has been connected on my network !!! is that possible ?? ???

I read through that page over and over again. I guess the frustration of borking the system prevented me seeing that sentence. I guess I thought I could do it logged in via SSH but that didn't work. I went and put a monitor back on the machine and did it locally and it worked. Also, being that it is now 2AM when I'm normally asleep at this time may have something to do with the oversight. It is back and working properly again now.

This works.  I finally got it working, had to release the IP from my router.  Now to create another vlan for my wireless network :)

Great suggestions guys, of them I like Derelict's tcpdump loop. I'll have to give it a try.  I did find that the latest managed switch firmware now supports a mirror port and will soon support a packet header only mirror, so it remains an option. But before I go this route, I had a recent discovery I thought I had ruled out but appears relevent.  I've kept an eye for drop patterns and see now that, although random, it hits on 15 minute increments such as 4:22pm, 4:37pm, 5:07, 6:07, etc.  Although nothing in the log corresponds. However in CRON is only one 0,15,30,45 and that's /etc/rc.filter_configure_sync .  I changed the interval to */60 and now the drops don't occur more than once every 60 minutes.  So what is this for and does it have to be on such frequent intervals?  Perhaps a better question is how might it cause the drop so I can modify or remove the root cause?

This issue is separate from the NAT one. For that case you'd have to disable pfsync to stop that.

My ISP supports MLPPP, as I said, its working… Both links are up as per my ppp.log I would just like to find a way (and maybe I have to parse the log and create my own widget) to show current link status per ppp connection.. [wan] Bundle: Status update: up 2 links, total bandwidth 128000 bps So I would assume that the ppp.log would show if a connection goes down, and when I get a chance I will take one down my unplugging the phone line and see what the log shows.. Not sure if its only on initial connection, or on some fault that it is updated.. But before I went and reinvented the wheel, I wanted to make sure there wasnt a package/script someone else had made to do the same.

Yup, you're correct.  If it was done right, it would be working. Turns it was an IPSEC phase 2 configuration conflict.  I had one of my techs build the tunnels and he decided to use a /16 to summarize the 192.168.0.0 networks in the phase 2 entry.  So the firewall was trying to IPSEC everything.  Fixed the CIDR notation to get away from the networks in use locally on the firewall and all is well now. So yeah, you know, just configure things correctly and things will work…  :D

Rumor has it that the problem was solved yesterday, and we will test it in production, at the start of next week. Solved with adding VIPs as you said Stephen, i will write a status and follow up on this when its in production, with the resolution incase someone else misconfigures the same way i have and stumples on this thread later. Thank you for the help :) /shh

The feature request is specifically for  'auto-disconnect'. There are a lot of providers which charge based on the connection time. So there is a need to bring up and down the ppp session. And ignoring this request is a deal breaker for some of us.

Upgrade to 2.2.4. Looks like you're losing power and ending up with corrupt group and/or passwd files, which is fixed in 2.2.3 and better in 2.2.4.

@cmb: Is the WAN actually link flapping in that case? See re0 link down/up messages in the system log, see the modem and/or WAN NIC losing its link light? Apologies for being unclear. No, by those tests it was not flapping. I usually have a small switch between re1 and the CM to prevent exactly this and dhcpv6 annoyances. I tested both with and without the switch in the middle and the result was the same. (re1 - WAN on the APU2 - and the CM Ethernet port are the only things on that switch.)

In the docs you find some points that should be checked in that case: https://doc.pfsense.org/index.php/Unable_to_Access_Some_Websites If the Router is connected to the ISP there's often an adjustment of the interfaces MTU required.

Well tested it so far with 2.2.3 and its killing off the internal interfaces states in effect working as I'd expected it to work doing the same youtube test as before, but as I write its still not killed off the WAN interface established states some 20mins later with Firewall Optimization Options set to normal. If you have a fixed IP, I wonder if these wan side states will ever get killed off? I know those on a variable ip will get killed when the ISP forces a new IP address, but how will the fixed IP established:established states work if they have scheduled vpn connection between sites? Will we see a build up of established:established states or will they eventually disappear? Edit. The wan side established state to youtube got killed off after 25mins, so google/youtube keep their states open for 25mins, but the vpn situ will be an interesting test.

Shrug; will probably sit there for ages… I essentially gave up on any remote syslogging - unless you have all servers running pretty much the same OS, you always end up with messy crap. Plus, the syslog daemon on pfSense is not exactly a masterpiece when it comes to remote logging (#1940 and others.

The default is checked (disabled), where you had it unchecked it was enabled. That's not the most clear config setting, need to make that description more clear. Glad that took care of it.

@doktornotor: Have you seen this checkbox? As a matter of fact : I saw it. Unchecked it  :) I'm syslogging to a 'huge' NAS, so it never bothered me, this httpd flood. They were just there so they remind me that 'something has to be done'. Now, my logs dropped 75 % in size  :)