Can't replicate that. Set password to password on interfaces.php for the interface, saved, applied changes. # grep password /var/etc/mpd_opt1.conf         set auth password password Changed password on interfaces.php to asdfasdf, save, apply changes. # grep password /var/etc/mpd_opt1.conf         set auth password asdfasdf Same if changed under Interfaces>assign, PPPs tab. Works fine. Also connects fine where I change the password PPPoE server side. The mpd_<interface>.conf file in /var/etc/ is the only location that resides on a running system. The data that creates that file is in your config.xml. If there's some scenario you can replicate, please post back info.</interface>

It's not so much a vulnerability as extremely insecure settings the affected vendors have used. Some vendors have again screwed things up here. Again, not us. Really no diff than: https://blog.pfsense.org/?p=688 The changes within miniupnpd are to prevent people from using insecure config settings, not to fix a vulnerability that exists where it's sanely configured. For pfSense, don't select any Internet connection interfaces in the Interfaces box in your uPnP/NAT-PMP settings and you'll be fine. Even if you did pick a WAN there, you'd also have to add a firewall rule on WAN to permit the traffic in. The affected vendors apparently configured it in such a way that it listened everywhere, and was automatically allowed through without firewall rules. Neither of those have ever been true here.

@stephenw10: How do you have the sysctls set in the above setup? I believe they're set to the default behavior of only filtering on the member interfaces: net.link.bridge.pfil_member = 1 net.link.bridge.pfil_bridge = 0

here you go https://forum.pfsense.org/index.php?topic=82232.msg449847#msg449847

Seems to be a common problem. I have the same and it's also described here: https://forum.pfsense.org/index.php?topic=83032.0

Thank you.  That works!

It works for me on an APU with https://snapshots.pfsense.org/FreeBSD_stable/10/amd64/pfSense_HEAD/.updaters/ or https://snapshots.pfsense.org/FreeBSD_releng/10.1/amd64/pfSense_HEAD/.updaters/ Using the amd64 version, full install. Crash reports must be looked up by IP and submission timestamp. We can't look them up by what sort of system submitted the report.

Looked harder - this is a test APU.1C system. Some time I had changed OPT1 from a WAN-style interface getting DHCP to a LAN-style interface with its own static IPv4 and no upstream gateway. OPT1_DHCP gateway was still in the system, with alternate monitor IP 8.8.8.8 and was even in some gateway groups. It was included in apinger.conf and thus was being monitored. It was using srcip of the new OPT1 static LAN-style interface - 10.52.1.1, and 8.8.8.8 was reachable from there out the normal WAN, so apinger reported the "gateway" up. I guess there are some "issues" in changing an interface from WAN-style to LAN-style and having all the old gateway settings/group membership… cleaned up. But I suspect it is the same on 2.1.n, so not a 2.2 regression. Could be looked at some day...

Retest with new config, starting from default was also failed! Steps done: set to factory default assign Interfaces, wan (dhcp eth), lan eth create internal root ca with GUI create Server Cert from localCa  with GUI create mobile ipsec, all setting default, Xauth section: select internal database, Group Authentication None add pase1: all Default, but Authetication set to mutual RSA, main  mode, Identifier local and remote set to ASN1, select ServerCert and local CA add pase 2 : all Default enable IPSEC VPN, log's show loaded configuration con1 loaded. If I check /var/etc/ipsec/  I can see missing configuration: ipsec.d/private/    -> empty no private key! ipsec.d/certs/  -> empty no cert stored ipsec.secrets    -> file exist but empty  " : RSA Keyfile" should be in to point to key -> Bug seem to be present also in  legacy config,  IKEv1+ main mode + mutualRSA so it seem to be not related to IKEV2 as originally suspected. Any ideas what might be wrong? Is there someone with Cert based "mutual RSA" + "IKE main mode" working 2.2 IPSec ??? (tested on todays snapshot 2.2Beta on AMD64)

Smoothly upgraded my box to 2.2 thanks for your efforts guys!

I haven't got around to using TCPdump, will have a look over the weekend. That is weird: have you changed iptables?

Honestly I am just using squidguard to filter adds.  It does a decent job and makes it seamless to users. I see squidguard is not being maintained also.  Hopefully since it's not working, the devs will remove it as available in 2.2.  Something is broken in the packages to me if they are flagged as compatible with 2.2 when so many are not working at all. Dansguardian is the only alternative I see for squidguard.    Anyone test our dansguardian with the older 2.X squid and see if it works? 2.2 at this point is not ready for prime time if the main packages are falling apart.

Yep. Looks like it's the same in 2.2. @https://www.freebsd.org/cgi/man.cgi?query=iwn&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html: iwn supports station and monitor mode operation. Stick with Atheros. At this point it seems by far the best supported wifi hardware in FreeBSD. Steve

@charliem: The bandwidthd package seems to trigger killing php-fpm – for some users.  Are you using that package?  If so, try removing it I had this happen with bandwidthd on and off. The old -ALPHA snapshot I reverted to did not have bandwidthd. I will snapshot and try to upgrade again later this week. In terms of other stuff pfsense is running pfblocker is basically it.

I am having the same issue with both esxi 5.1 and kvm, i cant even get to pfsenses with the ip it assigns

@firewalluser: @bmeeks: Well, that extra functionality is what disappeared due to the tightening of security on the pfSense GUI pages. That explains that. Thanks! I will look into a better method within the Snort and Suricata packages.  I am not happy with the current stop gap measure I put place in those packages. Bill

Interesting observation.  I do have multiple wan connections, but there is at least one issue with routing traffic out the correct interface / gateway, so I'm not currently configured to failover / switch between WAN links.  The observed behavior all happened utilizing a single WAN link. I will test killing the the states for the frozen connections next time I see this.  Thanks for the suggestion.