@ermal: Just create firewall block  rule and specify the schedule that you need under schedules. What Ermal says. I have this too (with some help from Phil.Davis to get it to work  ;D ). 1. On the top of your LAN create a block all rule, and assign a time schedule to it (for example: off at 22.00 - on at 08.00). 2. Beneath that, have your pass rules. 't Works  ;D

In our company, we have all ap connected with dhcp, because we have enough power and have not fixed places for APs, they change every month. But here i think you have not so much APs and it will tactically clever to set every ap an static ip. You know exactly where the AP is in the network and don`t have to look for the right ip of AP XY. The next thing is, we are speaking here of small business and home devices. So this is only my mind, but it would save cpu and memory if you don`t set up a dhcp server. Less to do for one device, more power for other services.

@doktornotor: Like, read the docs? https://doc.pfsense.org/index.php/Restrict_access_to_management_interface Read the docs?  :) Believe it or not but I have already read the page you are referring to. I was looking for an easier, more straightforward solution than "Disable webGUI anti-lockout rule".  Perhaps this is the way to do it after all. Thank you for pointing me in the right direction. 'How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?' Sherlock Holmes Quote-The Sign of Four

It seems this is just a WiFi issue. When a plug a PC into the private LAN I get a 192. address from pfsense.

@jimp: Once a bridge is created it does appear in the interface list on Interfaces > (assign), at least on 2.x+. It is a choice in the drop-down list, so you click + to make a new interface and choose the bridge entry from the drop-down, then save. Hi Ok so that is the part i am confused also , and its not working either for me 1- Once a bridge is created it does appear in the interface list on interfaces Yes i go on Interfaces–>Assign (create a new interface called wlan) and activate this interfaces linked first to my PCI card Ath0 showing up on the drop down menu list of pci cards available when creating new interface. Once i click activate this interface i then enter all the 802.11g settings standard no wpa keys or encryption used at the moment. I click on save and apply modifications 2- i then go back to Interfaces --> Assign --> Bridges (here i select add bridge new option and select my LAN and wlan interfaces in menu selection) then click save and below shows up the following information: BRIDGE0          LAN, WLAN          bridge LAN and WiFi interfaces Ok so now i am confused on tutorial is asking me to go back to interfaces –-> assign -> and put and save on my LAN interface istead of my rexx adaptor card the newly added to drop down list menu the bridge card ???? *** UPDATE *** You need to then navigate back to Interfaces / (assign) and on the Interface Assignment tab, assign the newly created BRIDGE interface to LAN. This is the address you want to assign your IP address to. i did that before and saved and lost all my LAN,WAN,wlan conections had to reset factory defaults on pfsense2.1 i also tried going on my ath0 card wifi interface menu option and change from  athxx card to briged wlan lan in menu list  but this also crashes my lan configuration. any hints on how to do this properly…? at last do i need to create another wifi interface with the bridged option from menu drop down list?? if so whats the poiint of having 2 wifi interfaces enabled?

I can't help you,but wish you!

@ChamPro: With 1 device accessing the AP, things were good. With 4 devices,  then they're getting disconnected. The device labeled MAC1 is having the most noticeable disconnections. Associated or ad-hoc peers ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS ERP MAC1 1 10 1M 11.5 0 34090 40592 EPS AE MAC2 2 10 11M 10.5 0 188 3616 EPS AEP MAC3 4 10 11M 11.0 0 102 28368 EPS AEP MAC4 3 10 9M 14.0 0 194 4064 EPS AEP Says MAC1 is only 1M is it far from the AP? That is horrible

@ofacesig: Where can I get the log?  This is just what I'm reading for the local console.  and yes the card works fine in a windows machine. dmesg and /var/log/system.log

So, after some changes, I've managed to get things seemingly working again.  What I did was disable the static arp option for the wireless router and everything seems to have been fixed.  Can anyone tell me why that would cause such a problem? Edit: Actually, devices seem to be connecting again, but now the whole network seems really sluggish.

Have you tried to replace the public switch with something else? Sound like it might be a ARP issue of some sort. If you have a redundant pfSense setup you might want shut down one server to see if it is part of your problem.

You can not set the same ip on both interfaces. If this is what you desire then create a bridge. Sound like you hit a bug because you should not be able to create a interface that has the same ip. Change the IP to a different subnet or create a bridge between LAN and WIFI. I recommend you use a different subnet and not a bridge. IntraBSS has nothing to do with IP conflicts so there seems to be a verification bug somewhere if you actually have 2 interfaces with the same IP already set.

Yes, you can do it with pfSense, but Layer 2 (the access point and switch)  has to present pfSense with two different networks so it can do its work.  They can be VLANs. Maybe you can take it out of AP mode, check the box, and put it back in AP mode.  Or get a real, VLAN-capable access point because pfSense will see them all as one LAN anyway so you're probably wasting your time on that gear since isolation is what you're after. The best deal in vlan-capable APs is probably Ubiquiti (ubnt.com)

Yeah I am with yeah, would never use a 615 in a commercial setup. So Las Vegas huh, where abouts?  I grew up there - left in 83, graduated from Western HS.  Alta & Decatur was decent sized intersection.

When you start flooding WiFi with multicasts, it will obviously go the shitty side up… Cannot see how is this a good idea at all. Could be a bit better with IGMP snooping, however still bad idea. BTW, nothing special wrt pfS. See e.g. http://wiki.openwrt.org/doc/howto/udp_multicast