@brandonpoc:
I'd connect in and reinstall 2.2.6 on the virtual machine but I can't because I can't VPN in. I don't understand why it was necessary to completely nuke it (and not provide a package, as far as I can tell, for reinstalling it for those dependent on it).
There is always a balancing act between convenience and security. It is not surprising that the pfSense team, as responsible vendors of security software, have taken the decision to remove older security standards that are known to be weak or compromised, also to configure system components to require security best practice. The removal of the PPTP server had been advertised for some time - there were numerous posts in the forums and it was clearly mentioned in the 2.3 release notes. There is an argument that the auto-updater ought to point the user to the release notes before allowing the install of a major upgrade, which has been suggested elsewhere in the forum. The new modularised structure of pfSense should allow for more frequent, smaller updates, which will help prevent the install shock of larger updates. Whether an update is large or small, I would argue that it is unwise to install a new version on a production firewall remotely without any form of physical or remote 'lights out' access. Upgrading one member of a clustered installation is not entirely foolproof, as it might prove impossible to force a failover to a working server remotely if the upgrade goes wrong.
I believe it was a deliberate decision not to create a PPTP server package. Those users that had ignored the warnings in recent versions of pfSense to discontinue use of PPTP as a VPN protocol would likely have installed the package and continued to use PPTP, even if it was inappropriate for them to do so. Not every user is competent to evaluate whether PPTP is still appropriate for their environment in the light of the known brokenness.
As has been said, you can either rely entirely on encrypted protocols (in which case a switch to SNMPv3 would be wise, if possible), or move to a supported VPN standard. divsys has given you a couple of suggestions for OpenSSL support in OS X. You might also like to consider IKEv2 - with carefully chosen parameters, it can work using the built in clients on a wide variety of OSes (though you may well find that the strongSwan app works better than the built in IKEv2 functionality on Android - you can find the app in the Google Play store). IKEv2 tends to be much less troublesome than IKEv1 IPsec.
The historic security philosophy was to leave old, weaker standards enabled for compatibility. This approach became discredited and has been abandoned in recent years, as people were leaving weak and broken settings enabled, such as the pathetically weak 40 bit export cyphers in SSL, also the trivially broken WEP. These old standards provided no more than an illusion of security and created an unnecessarily broad attack surface. With many of the recent SSL/TLS attacks being downgrade attacks, the risk of leaving old standards in place implemented by poorly maintained code become clear: the time had come for these older standards to be retired and the code removed. The recent forced upgrade to SHA256 signatures in SSL/TLS certificates driven by the browser vendors is another example of forced abandonment of an older standard - in this case, the questionable SHA1 hash function.
Other hardening in pfSense 2.3 can catch out the unwary. WEP has been removed from the wireless code, as it is utterly broken and there are few wireless devices still in use that do not support at least WPA (though it is best to use WPA2 with WPA mixed mode turned off if all devices support WPA2). TLS 1.0 is not supported any more due to security concerns, so those still following outdated advice to disable TLS 1.1 and TLS 1.2 in their browser will be unable to connect to the user interface in HTTPS mode. I got briefly caught out by the tighter requirements for key exchange imposed by the SSH2 server in 2.3 - I tried connecting to a newly upgraded box from an SSH profile on a secondary workstation that did not have modern DH and ECDH methods enabled, so I couldn't connect until I enabled a suitable key exchange method.
