HELP - Upgrading has Crippled Our VPN…



  • I clicked on the Automatic Upgrade for pfSense, like I have so many releases in the past, to find that I could no longer connect into our network via VPN. Luckily we have one Linux box exposed to the outside that I was able to tunnel in through to get to the pfSense server, and to my chagrin, PPTP is missing. I looked at the release notes and - indeed - PPTP is removed because it's "insecure" (but, of course, we're not allowed to determine what secure enough is or is not for ourselves I suppose).

    The reason we used PPTP is because it is damn near universal. It's essentially the only VPN software I've been able to get to work with Mac OS X's default "VPN" settings in the system's networking/connections options. Anything else - "Cisco IPSec", or "L2TP", do not work for me with pfSense. I have tried time and time again to get IPSec to work, following at least a dozen different how-tos, to no avail.

    Never mind the PHP errors that were being logged, something about CARP functions not being found.. and other oddities.. going on…

    I even setup OpenVPN and was able to get connected on a subnet outside the LAN (our LAN is 10.55.0.0/24, this network I had to specify was 10.54.0.0/24) but, of course, I have to add explicit routes for every machine that doesn't have the pfSense box as its gateway to route through pfSense to get to us. So I went ahead and tried to setup, instead of a "tun" tunnel OpenVPN instance, a "tap" OpenVPN, and followed at least two guides on how to bridge into the LAN so I could share an IP on our 10.55.0.0/24 network (like we were able to with ease with PPTP) with no luck either. In fact, this seemed to have messed something up to where OpenVPN won't even launch properly. Hell, the webConfigurator now won't even launch at boot.

    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). We don't care if the encryption has been compromised - everything we do over the network is encrypted with the sole exception of SNMP. .But I digress.

    So should I just give up or reinstall 2.2.6? If I can even get OpenVPN running again, how do I make it to where I can OpenVPN in with the same IP subnet as the LAN? With PPTP it was dead simple, and just worked, from every Windows, OS X, Linux, Android, etc. device. Nothing else works.

    Le sigh. Woe is me.



  • At the risk of opening the proverbial can-o-worms….

    If OSX is your OpenVPN holdup, what's wrong with Viscosity (small cost ~$9) or TunnelBlick (free) clients.
    Both of them provide an update to a sorely missing piece of the OSX architecture - OpenVPN access.
    Either option is long proven to be very effective and readily configurable.

    If you really can't live without PPTP, you're very much better off to reconsider your approach and just enable NAT style port-forwarding on the protocols you need.
    You'll end up with the same level of security that PPTP gives you (very little to none), ease of use for clients (just address at the correct port) and when you have a security breakdown, you can track the port it's coming in on (versus hiding it behind a non-existent encryption layer).

    Just my $.02



  • @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.


Log in to reply