Ok I found the issue. Due to a bug in the gui-code, the PAP-setting wasn't written to disk. After fixing this, everything now works. https://github.com/pfsense/pfsense/pull/1472 /Basse

@galto: To try an understand how pfSense works, I was going to see if I could figure out how the captive portal and radius plugin implemented. I have a demo VM setup. My VM setup is working as expected. I also have a cloned the repository. But now realize I don't know where to start trying to understand the implemented architecture. Are there any guides that would be a good starting point? Nothing great, but for what you're wanting to dig into it won't require much. Check out the development board here. https://forum.pfsense.org/index.php?board=32.0 But mostly all you need to know for what you're looking at there, check /etc/inc/captiveportal.inc and you'll find all of how captive portal works. Find the specific part there that you're after, and you can trace functions further from there as needed (most of which will be from something in /etc/inc/).

I figured out what was going on and I am posting here in case anyone else has the issue and can use the information… It turns out the black arrow pointing to the left in the interface column in the firewall log means that it is a communication that is OUTBOUND from the WAN interface itself, not from a host using the WAN interface. This was happening because I had created a separate VLAN (say, VLAN5 at 192.168.5.0), assigned an Access port to it and set it as that port's PVID. I had then connected a LAN port on a Linksys 4-port router to that port on my L3 switch thinking that the Linksys would just act as a dumb switch and allow the wireless clients to connect. What was happening is that a wireless host would communicate OUTBOUND, and the external host would reply but the NAT on the router was routing the reply back to the WAN port on the firewall (since, to the Linksys, the initial communication came from there) rather than the internal host that had initiated the conversation. When the WAN port would attempt to reply, the default block rule blocked it and it was logged. That's why it continued to block and log it even after I set a rule, as a test, allowing the WAN port to communicate externally to any IP using any protocol. To fix it, I reflashed the router using DD-WRT which allowed me to set it up as a true dumb switch, which also allows wireless clients to connect and seem to the rest of the networks like they are simply hosts physically connected to one of the physical ports. Now the router does no NAT, the WAN port on the router is disabled and everything is working as it should. Thanks again to marvosa for the time and assistance.

OK,I will use livecd to test NIC.I hope can upgrade to 2.2  :D

Just pick option "15) Restore recent configuration" from the menu and then "1) List Backups" to see what is available. Then either go with the one you hope will fix your latest goof or just try the newest one and be prepared to go though several of them if your error wasn't recent. The entries have some info available but nowhere what you can see from the GUI view diff option. Here are a few of my entries for an example: 30. 2/3/15 01:27:52    v11.6  admin@172.16.1.14     /services_dhcp_edit.php made unknown change 29. 2/3/15 01:28:35    v11.6  admin@172.16.1.14     /services_dhcp_edit.php made unknown change <snip>07. 2/4/15 13:00:46    v11.6  admin@172.16.0.16     /services_dhcp_edit.php made unknown change 06. 2/4/15 13:02:46    v11.6  admin@172.16.0.16     /services_dhcp_edit.php made unknown change 05. 2/4/15 13:14:41    v11.6  admin@172.16.0.16     /services_dhcp_edit.php made unknown change 04. 2/4/15 15:33:56    v11.6  admin@172.16.0.16     /services_dhcp.php made unknown change 03. 2/4/15 15:35:31    v11.6  admin@172.16.0.16     System: 02. 2/4/15 15:36:40    v11.6  admin@172.16.0.16     /services_dnsmasq_edit.php made unknown change 01. 2/4/15 15:36:50    v11.6  admin@172.16.0.16     /services_dnsmasq.php made unknown change –-------------- kejianshi, I'm sure with a bit more experience I'll learn to make worse messes but so far things are good.</snip>

I tried using the DNS forwarder and using the public address for mail.mydomain.com but unfortunately this did not resolve the error but when adding the private address (172.16.0.4) in the E-Mail server textbox for notification all worked fine.

Sorry, my fault. It hat nothing to do with the php-changes from version 2.2 -> i checked my Firewall settings and found the mistake. Thanks

@johnkeates: I posted this in a different thread, I hope it's okay to semi-double post You're more than welcome to cross-post solutions across however many threads are relevant.  :) There are probably a dozen different threads around here on this same root issue. Feel free to post it in however many threads are relevant. Many people only follow specific threads and may miss a fix for the same problem posted in a different thread otherwise. pf does have a history of breaking checksums in certain areas, though I can't say I've seen any of that recently outside of this particular issue with Xen. It's probably a combination of pf+xn from the sound of your description. Can take our /tmp/rules.debug file, copy it over to stock FreeBSD, kldload pf && pfctl -f rules.debug (assuming stock system has same NICs) and see what happens. I'm definitely curious on the results.

thank you, the patch solves the problem.

Different versions of firefox switched between letting the user store the pfsense web cert and other times not. Whats the error message you get or do you mean the default error message saying this cert is not trusted when you first visit the pfsense web login page?

@Supermule: Something like this?? You need to set the interface to the one on which the DNS requests arrive. In most cases this is the LAN interface or whatever your clients are connected to. See attached image. [image: dns-override.png] [image: dns-override.png_thumb]

@switchman: Login with SSH and open the shell. Run “/usr/local/sbin/ufslabels.sh”  - It's required for older installs, or installs that have been upgraded to 2.2. It shouldn't be needed for a fresh 2.2 install /usr/local/sbin/ufslabels.sh This isn't required. ahci is compiled into the kernel. It's probably better to remove that entry (though it shouldn't hurt anything) Use the Diagnostics > Edit File command to create and add the line ahci_load="YES" to “/boot/loader.conf.local” Some notes changed/added inline.

Do you have VLANs? Is WANFFTC on a VLAN of re1? Post some example log entries so we can see what they are related to.

Uptime 10 Days 07 Hours 49 Minutes 23 Seconds Everything is working fine.  Thanks again everyone. -ram

You need two VLANs to the AP.  I will assume these are 10 for the LAN and 20 for the guest: Create VLAN 10 with a parent interface em1 Create VLAN 20 with a parent interface em1 Create a bridge with members em0 and em1_vlan10 Assign LAN to Bridge0 Set em1_vlan20 to be what you want for your guest wi-fi Tell the AP to tag your LAN ssid with VLAN 10 and your guest SSID with VLAN 20.

bump Is it true that the IGMP proxy can only handle proxying between different interfaces, not between VLANs sharing the same network port? Thanks.