@CyberTiVo: There are many reasons to have a quick simple way to have spare pfSense backups since I have had quite a few USB sticks loose their cookies. Yes, there are many reason to have a backup. There are zero reasons to make backups by using completely broken methods like trying to dd a live system. Absolutely horrible idea leading to inconsistent state and broken filesystem.

what is Apinger using as the destination ip (my gateway ip doesnt reliable respond to pings) maybe it prioritises other internet traffic over the pings also i wouldnt trust that graph (apinger)find a different tool whats your cable modem show http://192.168.100.1

I'd be happy of he would just answer the simple questions he's being asked, such as What is it that you're really trying to do?

@Panja: @Panja: Could the restrict access be done with FreeRadius? I'm going to setup radius for wifi authentication anyways. To answer my own question: not possible… I can restrict logging on to the network, but already connected devices stay connected. So for instance if I set the user logon times to be available from 07.00 - 21.00 hours. When the device is connected between this hours and does not disconnect, than the connection is still available after 21.00 hours. Only when the device gets disconnected and tries to reconnect, than the connection is not available. So setup a cron job to flush the states at 7:05.  It may interrupt a few legimate things, but it whacks the desired connections and then if they try to reconnect, they get hit by the scheduled block.

Hi David, many thanks for your reply…. to answer your question: we have several costumer connected to us via microwave. Our DC is for this costumer the internet breakout. I am the owner of the external ip-addresses. I am responsible for the communication, to and from the internet (in German called "Störerhaftung"). To guarantee that a specific costumer use a specific IP in this range , I need PPPoE, or I must use for each costumer his own VLAN with an overhead  of unused addresses (Broadcast, Net-IP). I will try your suggestion... Dirk

Thanks!  That makes sense. I should have realized it when it turned grey it was no longer being considered, but it also tries to calculate it then turns it grey which threw me off.

Looks like it should be working.  Put something else on the WAN side instead of whatever network you're plugging into and see if it works. Or start doing packet captures. Or reset and start over like I suggested before.

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.