If you are putting the ap on the lan port of the pfsense box and you have dhcp running on that lan interface, say pfsense lan interface is 10.0.0.1 with dhcp server set to give out 1.0.0.3-10.0.0.X you can give the ap a static ip of 10.0.0.2 on the interface used to connect to pfsense and it will work on the ap stop dhcp dns and firewall set 10.0.0.1 as gateway and dns.

I, after a deep dive in packet analisys an sniffing i found out that  the problem was due to large packets with a strange (0.06 sec or greater) delay. Those packet disappears without any warning when hitting client interface. I finally found a workaround with a standard rule on client interface client --> NLB:80 with advanced features state type = none Bye, Chris

Hi Dose it happen no matter what setting you changed. It sounds like you are setting a new ip on the interface you are connected to or maybe adding a firewall rule that is blocking you.

Yeah I should probably think about more productive things, but I'll go check when I actually get some sleep. It's 7 AM for me now, I was supposed to sleep 9 hours ago.  ::)

@Digitallydone: I figured it out. pfsense won't let you use your original LAN IP address in addition to the VLAN interface ip. So I went "interface -> LAN". Under "IPv4 Configuration Type" i select "none". But the remaining VLANs interfaces kept their respective ips. I gave it a reboot and "voila" problem solved. This should be the case with any router. On a trunk interface all traffic needs to be tagged.

It seems like you are plugging in both of the ports on your pfsense router to the same switch?

@guitarpicker: The custom import was a one-time action, and does the same thing as if the users were entered via the GUI.  After this import, all new users are being added via the GUI.  I am not running any custom scripts Sorry i wasn't clear. I meant: what about a custom script that save user somwhere, download it at boot and then readd it (maybe in import-like mode)? Firewall would be reacheble even without users and then wil readd it again. But u should be able to: 1. prevent pfsense to save itself the users 2. store them (local persistent HD or remote) 3. import them at startup (maybe the simpler things to do) @guitarpicker: The deletion happens at every boot is just how pfSense (and upstream m0n0wall) work - not by any sort of customization that I have done.  You can see for yourself in the source code for the local_sync_accounts function (https://github.com/pfsense/pfsense/blob/f1551428c4fe708232fc80239ec207640b058a28/src/etc/inc/auth.inc#L378) which gets called at boot up.  The general flow as seen in the comments is: Delete local users Delete local groups Sync (import) all local users Sync all local groups This simple and rather foolproof method of synchronizing the user accounts with the configuration file could be optimized for performance, but the code would be immensely more complex to do so.  I think the lion's share of the delay is due to calling the local_user_set function (https://github.com/pfsense/pfsense/blob/f1551428c4fe708232fc80239ec207640b058a28/src/etc/inc/auth.inc#L450) for each user on each boot, which has a laundry list of things to do when setting up a new user. It sounds like this isn't a high-demand feature.  I would much rather have an option to use FreeRADIUS without storing the plain text passwords than to spend a lot of time optimizing the local account sync process.  I don't think this is likely to happen either, since the whole reason they store the passwords is so that you can change the encryption type in FreeRADIUS without losing all the accounts. Fortunately, pfSense has been rock solid and I haven't needed to reboot much.  I schedule it to reboot at night when I need to, so that the delay doesn't affect our users. Looking at code it call system binary file to read and write users correctly(and set them the password): $user_op = "useradd -m -k /etc/skel -o"; $cmd = "/usr/sbin/pw {$user_op} -q -u {$user_uid} -n {$user_name}". " -g {$user_group} -s {$user_shell} -d {$user_home}". " -c ".escapeshellarg($comment)." -H 0 2>&1"; Write users differently implicate a function that write "X" users directly to user file being careful to not corrupt this file.. it seems risky :D

Generally where you have IPv6 enabled, but have it set to block all IPv6 under System>Advanced, Firewall/NAT.

Thanks @heper. @jahonix these are special events, definitely not day to day use.  THe bandwidth hog is an intranet serving video  from an internal Wowza server.

@gokorn: Eveything works OK now. I did manually import settings for squid proxy.. I just have one question. Is this normal in services I have duplicates one is Squid reverse proxy and the other is Reverse proxy. Both menus show the same configuration. had the same issue, settings needed to be configured manually. but so far everything works fine .

It's probably worth posting a link to your findings in Redmine #2859. The code in question is in the interface_configure() function of /etc/inc.interfaces.inc (around line 2907):         $mac = get_interface_mac($realhwif);         /*         * Don't try to reapply the spoofed MAC if it's already applied.         * When ifconfig link is used, it cycles the interface down/up, which triggers         * the interface config again, which attempts to spoof the MAC again,         * which cycles the link again...         */         if ($wancfg['spoofmac'] && ($wancfg['spoofmac'] != $mac)) {                 mwexec("/sbin/ifconfig " . escapeshellarg($realhwif) .                         " link " . escapeshellarg($wancfg['spoofmac']));         }  else {                 if ($mac == "ff:ff:ff:ff:ff:ff") {                         /*  this is not a valid mac address.  generate a                         *  temporary mac address so the machine can get online.                         */                         echo gettext("Generating new MAC address.");                         $random_mac = generate_random_mac_address();                         mwexec("/sbin/ifconfig " . escapeshellarg($realhwif) .                                 " link " . escapeshellarg($random_mac));                         $wancfg['spoofmac'] = $random_mac;                         write_config();                         file_notice("MAC Address altered", sprintf(gettext('The INVALID MAC address (ff:ff:ff:ff:ff:ff) on interface %1$s has been automatically replaced with %2$s'), $realif, $random_mac), "Interfaces");                 }         } The thought occurs that replacing $realhwif (and the one seemingly incorrect occurrence of $realif) with $interface_to_check throughout that block of code might make the behaviour more correct - act on the interface itself except in the case of PPPoE, where you need to be acting on the parent interface.

I'm thinking just buy/build a cheap pfsense box so he can restart it to his heart's delight while I'm not home. Probably the best solution suggested so far. You might even find with a properly configured pfSense box as your main router, you're not restarting the router all the time to get your internet back. At minimum you should be able to figure out why you need to restart ( and maybe solve it….)

THANK YOU!!!

@divsys: Did you ever bring that up to the latest release (2.2.5)? Well worth the effort and would get you on a solid footing for troubleshooting (if required at all). Yes, I did that before I swapped the hardware.  Still had the kernel crashes and watchdog nonsense until I swapped the chassis.  Now the only remaining symptom is the LAN hotplug event (and my android clients for OpenVPN quit working).

I think the issue is fully understood and resolved, BlueKobold. BT Broadband and BT Infinity require PPP authentication, but this is merely to pass a domain to the BRAS to identify which RADIUS servers should be used for authentication. The password can be anything, as BT Broadband and Infinity authenticate based on the circuit ID inserted by the DSLAM's PPP Intermediate Agent. Chris had set the password to a single space but because pfSense doesn't enclose the password in "", mpd5 ignored the set auth password line in /var/etc/mpd_wan.conf and went looking for the password in a non-existent /var/etc/mpd_secret file. The resolution was to set a password that consisted of something other than white space.

As i am planning pfSense in transparent using IPv6, snort, captive portal i wonder if they can be configured in transparent mode? pfSense can be run in the transparent mode Squid can be run in the transparent mode Snort must be run in the transparent mode (only as I am informed I don´t use it)

Thanks for the suggestions guys. I've been dealing with this crash report for weeks now. I've already tried the latest version but had bad luck on implementing squid + squid guard. It seems that if I'm using the latest version which is 2.2.5, only https websites are accessible if transparent proxy is enabled. I'm also suspecting this is a hardware issue cause I'm using an old P4 machine with 512x2 ddr1 ram and 80gb of hard drive dedicated to pfsense. I'll try once agaain the latest version if this crash will disappear. Also, is there anyway to know if my processor supports 64bit version without opening the case. Like CPU-Z on windows. Thank you.