Sorry, one more question. Can we set the time interval for CARP? I mean pfsense send the CARP  message to another pfsense. Please advise.

I have went back to the old machine that was working like it should, but apperantly the same thing happen to it as well. The only thing I did was remove tftp package. I bring it back afterwards but that did not change a thing. So I found post that brings a clue  - http://serverfault.com/questions/506592/pfense-needs-to-be-rebooted-to-effect-a-change-in-existing-nat So what I did was I run - /etc/rc.filter_configure_sync And then I check the system logs and I found the updates performed : Oct 22 13:11:42 php: rc.filter_configure_sync: Adding TFTP nat rules Oct 22 13:11:42 php: rc.filter_configure_sync: Adding TFTP nat rules So regardless of how much I run this, it always do that. I do have now problem with the TFTP, I have add another TFTP server and change the address to that TFTP server and the configuration its not working until I reboot the system. I have factory reset a machine with pfsense and try to change something on the DHCP , map an IP and no result till reboot. How I can fix this problem ?

@cmb: Leave everything there at their defaults. Make sure you've bumped nmbclusters (though that'd result in a diff error log generally). https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards The second crash was everything at default.  The third crash was with the nmbclusters bumped to the recommended number for the Intel card.  I've tried turning off all hardware offloading for now and will see how it goes.  Been up for 1.5 days but it had done that before.  I'll report back. Off topic:  I've noticed that the chip runs hotter with PowerD turned on with "hiadaptive" than off (at least the first core).  Seems, from reading around, that PowerD allows 'turbo' speed to kick in whereas it will not kick in if PowerD is turned off (or another system setting is added).  I've turned PowerD off for now (default) for testing until the lockups quit.  Just found that interesting.

Hey Chris, I spent months using no-ip (free) with the Dynamic DNS service in pfSense… only to get these messages in the system logs: php-fpm[32255]: /rc.dyndns.update: phpDynDNS (xxxxx.noip.me): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. I found myself each month getting a notification from no-ip saying… "You need to confirm that you are actually using this service or your service will be disabled" (even though it's free).  So what was happening based on the log above... is that the DynamicDNS feature in pfSense wasn't informing no-ip that even though the IP didn't change... that it was actually using the darn service.  What I was doing each month was clicking an email link, going to the no-ip page and "Confirm by pressing this button". Your point is well taken to try using the Custom DNS feature of the Dynamic DNS service in pfSense... I just didn't think about it and came cross a way that I understood when I came across some free time.  I guess I just missed the elegant way and worked out a different solution that works too.  Like they say... there's more than 1 way to skin a cat. I'll still take a look at the Custom DNS feature in pfSense.  Linode is not at all like no-ip in terms of crying that the API doesn't get hit for 25 days... so it'll probably work out just fine. Maybe it would be helpful to have a feature in the Dynamic DNS service to explicitly control the update frequency to the Dynamic DNS provider, just to keep their system on notice considering the above case that I had?  I know how it is with feature requests and software... and I don't expect this feature to ever exist.  Just my 0.02. Thanks for your thought. Best, -Will

Hi Again, If you can send your cron table then i can help you about it. Regards, SGTR

A few general pointers for WiFi that will help you out … As some of the other people that have responded in this thread have mentioned some of these points, I've collected them here: Signal strength at BOTH ends is important.  How well you see the AP is only half the puzzle.  If the AP doesn't see the client equally as well, then its not going to work well.  Remember that an AP doesn't have the physical limitations of an antenna that'd you'd find on a tablet, meaning the AP's antenna probably works better than the tablet's. Signal attenuation is a killer: walls, crappy antennas, etc.  If you have any way of measuring the signal, you want at least -70dBm (yes it will still work, but poorly at -80dBm) from the AP at the client and vice-versa.  Also don't run your APs without antennas.  The radios inside are impedance matched to the antennas, disconnecting them generally makes it not work beyond a few feet. Interference is a killer: Make sure you are on your own channel, in 5Ghz, that's possible, but avoid DFS channels (52-144) since by law the AP must switch off and find a new channel if it detects radar.  As an additional point, if you run custom firmware in your AP, it may be tempting to select certain non-standard channels, just be prepared for a visit from law enforcement agents, big fines and equipment seizure especially if you're near an airport! Most people have no clue about 2.4GHz: Stick to channels 1, 6 and 11 (or whatever is standard in your country).  Otherwise you're just creating unintelligible noise for your neighbors, which is far worse than interference on the same channel, which can at least be understood and respected by all parties. Please for the love of God don't run 802.11n 40MHz in 2.4GHz, you're just being a pig since there's only 1 usable non-overlapping 40MHz wide channel in 2.4GHz. More power != better performance; in fact in many cases more power = worse performance.  Think of how you'd want to install speakers in a whole home audio system.  One super powerful speaker in a central location, or many smaller speakers scattered throughout for a pleasing uniform sound level everywhere.  You can also use the same analogy for lighting.  Same thing applies to WiFi, RF waves are like light waves, only they penetrate somewhat the obstacles. Don't forget WiFi is a half-duplex medium:  The radio can only send or receive, it can't do both at the same time AND each and every wireless packet has to be acknowledge or retries occur.  Consequently, your expected performance will be about half the connection rate, if that. Consider using iperf to validate your throughput.  Run iperf in both directions to ensure you're getting what you're expecting. In the end, unless you have the budget for Enterprise grade wireless, you have to work within with the above realities. –A.

Thanks KOM!

Hi, Thank you for your informaiton :)

There isn't really a list like that to view. You can see the connections on Diagnostics > States, and they are listed by interface, but there is no "why" – the "why" is up to the policy routing rules on the internal interface (e.g. LAN) and that part isn't retained in a visible way.

Thank you that is much more helpful and a lot less cryptic !

for ssh: -b bind_address             Use bind_address on the local machine as the source address of             the connection.  Only useful on systems with more than one             address. for scp it's trickier, but can probably be worked out with this: -o ssh_option             Can be used to pass options to ssh in the format used in             ssh_config(5).  This is useful for specifying options for which             there is no separate scp command-line flag.  For full details of             the options listed below, and their possible values, see             ssh_config(5). […]                   BindAddress

I believe the sAMAccountName in windows is limited to 20…  So guess you could get 4 extra characters that way..  But come on really why would anyone use such long usernames??

@firewalluser: The irony of what you suggest is, that the current setup where it shows hot plugging messages on the console is the only indicator I have when I plug an infected machine into a pfsense managed network and pfsense becomes compromised. Well sod's law I cant replicate the hotplug event again. Having read this thread https://forum.pfsense.org/index.php?topic=66908.0 as well as this thread https://forums.freebsd.org/threads/powerd-and-usb-nic.39207/ and a few others including some man pages, even though I'm using the built in intel motherboard nic (em0) with bios updates up to date I simply cant replicate the hotplug events. This was a default mem stick install with just vlans configured with 2 devices (a pc and rpi) connected to their own individual vlan. PowerD is off by default so shouldnt have been a factor, but seeing the hotplug event when I plugged a running rpi into the switch made me believe this caused the hotplug event to pop up on the console (didnt check system logs but since found out they do appear there). Whilst I was thinking this through, it did occur to me that monitoring the usb bus in much the same way a nic is monitored with IDS/IPS just doesnt exist. AV has it flaws, namely they have to find the virus first before they can search for it. Even then AV mainly just scans storage devices beit disks, cd's, floppies, network shares & mem sticks, for root kits and their like, some will also scan memory, but not very efficiently. DuQu2.0 I noticed when reading up the Kaspersky pdf's have only found traces of it on windows systems. Linux CD's are not hardened out of the box and having been hacked via linux which destroyed windows and backups, all my backups will be on read only DVD's from now on. But this got me wondered just how insecure systems are. It turns out you can remote access UEFI bios, some motherboards also come with 32MB of space for the UEFI bios when the bios code itself may only be 4MB in size, and theres some very detailed presentations around which show how easy it is to hack the UEFI bios as well as the old style and compromise them, one is only limited by their imagination as to the possibilities. It's possible to rewrite the firmware of some disk's so you could also use the cache to hide during runtime, and store to disk at switch off, in effect being able to hide from AV mem scans. Again skilled programmers needed, but not impossible https://www.reddit.com/r/netsec/comments/1jkuts/flashing_hard_drive_controller_firmware_to_enable plus it also crossed my mind, could the network cable in a rpi be used as a wifi antenna. I dont know as havent taken one apart, but when trying to isolate and eradicate whatever hit my system, its only by having some old software from the 1990's which gave me the break to see hidden 64mb partitions on memsticks as nothing showed up in gparted, but I could clearly see it when I did using wxhexeditor. Even now those memsticks are still isolated until I take them apart. So all in all, OS's and many industry standard practices still leave systems wide open for some serious hacking and I dont think most people have a clue just how easy it is for hackers with suitable funding.

Your ISP asked for an MRU (your MTU) of 1456, which your end understandably granted. You asked for an MRU (your ISP's MTU) of 1492, which was granted. Only your ISP can explain why they ask for an MRU of 1456.

It's simple. Do not use the bogons.