You might get help over at miniupnp site..  Your listening IP is going to be the networks on that interface..  But you have downstream networks, so that source does not fall to what your listening network is.. You might want to change your listening_ip to say 192.168.0.0/16 and see if that gets rid of the error and allows ports to be opened..

Which is more secure depends on several factors. FQDN aliases rely on DNS working securely. If you trust the DNS server(s) (as you really have to when using AD) and ideally are using DNSSEC, it is a good solution. I don't know whether pfSense resolves FQDN aliases using DNSSEC, though it is good practice to configure DNSSEC whenever possible. Make sure you test DNSSEC carefully, as it can be tricky to configure correctly. IP aliases are immune to DNS related issues, but can be a maintenance headache as they need to be updated manually following a DNS change. Enforcing restrictions on local users is best done using 802.1x on your switches and having your RADIUS server allocate the user to the appropriate VLAN based on user privileges. Assuming the connection between the switch and your RADIUS server(s) is appropriately secured (a dedicated AAA subnet is recommended), this prevents users working round restrictions by spoofing their local MAC address and/or allocating a static IP address. A user that cannot provide valid 802.1x credentials will be placed in the guest VLAN if you have one configured, or will have no network access at all. For wireless, you can use a similar approach based on WPA2-Enterprise. A suitably configured business grade AP will bridge the user's connection to whichever VLAN was allocated by the RADIUS server. If you wish to have fine grained control over access from the outside than 'whole network' rules, there is really little alternative to rules that use some form of alias, though it is worth remembering that you can create VLANs fairly freely if you have suitable switches.

^ who would of thunk that you would need a firewall rule to allow access… [image: zx4pom.jpg]

Changed ruleset to: pass a particular rule according to daytime schedule pass another rule according to daytime schedule etc and got rid of the: block according to nighttime schedule and it appears to work judging by the complaints I got when the daytime schedule ended. Thanks everyone.

@cmb: No need to have anything USB plugged in at all. PixArt seems like a mouse, maybe your mouse is flaky and is causing itself to disappear and reappear repeatedly. I unplugged the keyboard and mouse rebooted the pfsense machine message has went away thanks for the help i'll have to look into maybe getting a different keyboard or mouse depending on which one is causing it I'll plug them in one at a time and reboot the machine and see which one is giving me the issue. Thank you for replying to my post and giving me help.

No response at the console is probably because something/someone turned on scroll lock inside the VM (hit the up arrow to confirm, screen will scroll back if scroll lock's on).

@bruor: I use an ISP that has a seemingly half baked IPv6 implementation which is also impacted by a bug in pfSense. This problem is already under discussion in the IPv6 forum. @bruor: From time to time this will not work,  and that is because pfSense has multiple dhcp6c instances running which causes xid mismatch errors and requires me to shell in,  kill the processes, and restart the wan interface. Is there a client command that I can use in a script to get the wan interface to reconnect? As I just posted in that thread: /usr/local/sbin/ppp-ipv6 pppoe0 down ; pkill -xf '^.*dhcp6c.*pppoe0$' ; sleep 2 ; /usr/local/sbin/ppp-ipv6 pppoe0 up This attempts to bring down the IPv6 connectivity on pppoe0 cleanly, kills off any remaining dhcp6c instances for pppoe0, waits 2 seconds, then restarts IPv6 on pppoe0. Read the full thread for more information.

@johnpoz: "but i am unable to ping any computer/servers on the LAN side with 192.168.0.x addresses." Well yeah, why would you think you would be able to – since that 192.168.100 network is on the wan side of pfsense and would be hostile just like a public IP.. So unless you setup a port forward its blocked by default.  Also there is default rule to block all rfc1918 addresses even if you setup a port forward. If you want to use pfsense, You should really bring your wireless behind pfsense.  Get another wifi router and use it as AP, and disable wifi on your isp device.  Or get a real AP and again disable wifi on your isp device. I would also suggest changing your isp device to bridge or just modem mode so that pfsense gets your public IP right on your wan.. Thanks for the feedback, I did some reading and now I fully understand what is required. I will now act on your input/feedback and my reading. Thanks Again.

Yes.  Exposing the WebGUI to WAN is not the best choice when you have OpenVPN right there, built-in for free.  Use it.

Very true.. Some isp device might have filters put in place..  But seems odd that they would filter multicast traffic between switch ports.  But possible they might of done that between the wifi and the wired.. Not a fan of any of the devices where you put multiple technologies into one box..  Switch should be your switch, wifi should be AP(s) connected to your switch ;) and your router/firewall should be just that your firewall/router.  This way you don't run into any inconsistencies to how things work like a switch blocking multicast unless you specifically set it to do that, which any decent smart/managed switch would allow you to do. For example I have a low end smart netgear switch that allows you to enable igmp snooping, but can not limit or pick which ports that is enabled on etc.  Its either on or off for everything.  While my cisco switch gives me full control over stuff like that.

^What he said. You can also try Dansguardian, although it's mostly used for managing access to sites rather than direct proxying per se.

Also update my server address to the CN as per the certificate generated by ClearOS, still no luck…. :(

How are you checking the MAC address? Did you perhaps enable MAC spoofing in the interface options? Your ISP appears to only accept DHCP requests from verified MAC addresses, am I wrong?

@KOM: https://doc.pfsense.org/index.php/VoIP_Configuration This may apply to you: Set Conservative state table optimization The default UDP timeouts in pf are too low for some VoIP services. If phones mostly work, but randomly disconnect, set Firewall Optimization Options to Conservative under System > Advanced, Firewall/NAT tab. A keep-alive or re-registration on the phone set for 20-30 seconds or so can also help, and is often a better solution. Hey KOM, Thanks for your help. Just got back on pfSense and made firewall change as per your suggestion a few minutes ago. Will see if this stops the disconnections after a couple hours inactivity on the phone. I am not sure how to apply the 'keep alive'? Is that on the pfSense side or a setting on the phone side? Not really sure how to proceed. Thanks for your help!

did you put the rule it needs to be above other rules that would allow. Also curious are you natting from your lan to you wan?  If your wanting to use pfsense as router/firewall between your rfc1918 networks there is no reason to nat.. But out of the box pfsense would nat.  What did you use for the protocol on your block rule.. Default when you create a new rule to tcp… Which would allow icmp.

I understand, I will reinstall tonight after all clients go home :0 Thanks all for support :D

This is not a primary spam solution, but it does help. One thing I do that seems to word very well is: Install pfBlocker and block everything outside the commercially valuable countries (US and Canada for our company) Put your mail server inbound rule below these pfBlocker rules. Create a second MX record and install SpamD Point the MX record to your pfSense box. This way, mail outside the commercially valuable countries is subject to SpamD rules.