Assuming you have the correct credentials for your SSE account, OPNsense should work - though I have serious issues with Franco's attitude, also OPNsense have managed to ship some broken code in the past in supposedly stable releases (one stable release had broken VLANs, for example).SEE credentials are straightforwards, once one works out that which of the two provided passwords is for the broadband, and which is for something else.
That helps considerably. I'm with Zen, who put the user name and password for PPP on your customer portal pages.
Borked code, not good, especially when they claim code is tested - unlike PFSense!
pfSense release engineering seems to be pretty good; the release process is pretty exhaustive, snapshot builds are made available leading up to a release, the bug tracker is open to the public, the main repository is on GitHub with sensible pull requests being welcomed and Netgate's in house testing seems to be pretty robust. Minor regressions are almost inevitable in a product like pfSense that interacts with such a wide range of external environments, but these tend to get addressed fairly quickly.
It helps that pfSense has been fairly extensively modernised in the past few years and a lot of technical debt eliminated. The distribution is now modular using FreeBSD's pkg package manager and is based on up-to-date components (pfSense 2.3.3 is based on FreeBSD 10.3, the upcoming pfSense 2.4 is based on FreeBSD 11.0 - in both cases using recent ports for external binaries). The horrendous old build system from pfSense 2.2 and early has been retired to great rejoicing from those like me who had the misfortune to have had to wrestle with it. The pfSense team have made some tough decisions to modernise the platform including replacing the GUI from pfSense 2.3 onwards and eliminating both i386 (32 bit) and NanoBSD builds (the build designed to run from a memory card) from pfSense 2.4 onwards. The ideal platform for pfSense 2.4 onwards is a 64 bit single board computer with a small SSD or a supported ARM board.
The architecture of both pfSense and OPNsense suffer from the original m0n0wall decision to use PHP without clear separation between the user interface and back end; you have code that responds to a web GUI submission by directly manipulating the internal configuration in a single security context. Best practice would be that any code running in the web server does not have that level of privilege over the system as a whole. Whilst there are ways that the internal security can and has been improved in both systems over the years, pfSense has not dealt with this issue and I don't believe OPNsense have completely eliminated it either, despite setting it as a project goal.
This sort of issue is typical of long-evolved code. After all, pfSense and OPNsense are very different today to the original m0n0wall releases, which had to run on much more constrained hardware than we have today. The best way to get away from this design flaw and the numerous other burdens of legacy code is total reimplementation. The pfSense core team have hinted at the possibility of pfSense 3 being a total reimplementation in Python using privilege separated user interface and back end; possibly using a RESTful API between the two.
I would seriously suggest you consider going for pfSense instead; OPNsense is a fork of pfSense. As both OPNsense and pfSense are free to download and open source licensed, you could download both and see which you prefer.I've looked at both, and guessed it was pretty much horses for courses, OPS being a fork. Initially was going with PFSense for reasons not relevant here, but I was taken with the feature set in OPS, particularly its ability to use multi-cores. Whichever I use, it will be running on an old N40L microserver, which only has a dual-core AMD. I know its not the best hardware for the task, but on-board RAID and the 4 drivebays allow me to use some old SATA drives for caching and log-storage, it has two PCI-e slots so I can the additional NIC I need, and if necessary, a third.
The reason for the fork is significant - and I only have an outsider's imperfect understanding. I believe Deciso, the company behind OPNsense, used to be the European dealer for branded pfSense hardware. There was some sort of disagreement between Deciso and Netgate (the company behind pfSense), which led, in part, to Netgate asserting its rights to the pfSense trademarks in a much more robust way than it had done before, also to the build system for pfSense up to and including version 2.2 being moved to closed source with access available to those who signed a licence agreement. Deciso chose to fork OPNsense from the last open source version of pfSense and continue their business along their own track.
I may have some or all of that incorrect. Those who know the history will understandably not speak openly about it. It's "water under the bridge" anyway now. Current versions of pfSense Community Edition are fully open source again using the Apache 2.0 licence. The only restrictions are on the use of the pfSense trademark, which is understandable, as Netgate have to have ways of recovering the significant investment they continue to put into pfSense through commercial exploitation of the brand. Netgate have contributed quite a few improvements to the FreeBSD networking code, not least by working with some FreeBSD source contributors. Deciso do work with some FreeBSD contributors, but my impression is that their level of investment in FreeBSD is not at the same level as Netgate's. If you look at the commit log for the pf code in FreeBSD
(which is a part of the operating system where pfSense and OPNsense developers have a particular interest), you will see much more work originating from and/or sponsored by the pfSense developers than the OPNsense developers.
OPNsense have chosen to go in a different direction to pfSense - for example, they chose a different GUI framework to pfSense. There seems little prospect of the forks ever coming back together and I don't believe OPNsense have made any attempt to ensure ongoing compatibility of pfSense configuration files with OPNsense.
I don't think there's any reason to expect OPNsense to perform significantly better on a dual core machine than pfSense does these days. I can't remember if OPNsense managed to ship a FreeBSD 10 based release before pfSense. FreeBSD 10 has significantly better pf performance on a multi core machine than earlier versions. pfSense got stuck on FreeBSD 8 for a long time as moving to FreeBSD 9 proved sub-optimal and once FreeBSD 10 was available, there was a lot of work required to produce a release
. The OPNsense fork happened in the run-up to the release of pfSense 2.2, the first FreeBSD 10 based version.
I used pfSense before the fork and felt no reason to switch. I happen to get on pretty well with the pfSense developers and have contributed some code to pfSense, including support for RFC 4638 (PPPoE MTU greater than 1492) and some PPP and IPv6 related fixes. My involvement with Franco has been abrasive, as I noted in the FreeBSD bug relating to RFC 4638 support in mpd5
(the daemon used for PPP).
I don't make any money out of pfSense, nor have I ever contributed a penny to them. I run the free Community Edition on my personal router, which uses non-Netgate hardware (an old Dell server). Your N40L isn't a bad machine for pfSense - it has amd64 support, so if you choose pfSense, install the amd64 version now and you won't have any problems upgrading to pfSense 2.4 when it is released, likely at some point in the next few months. The only issue with using old server hardware is that it tends to be power hungry for the performance level offered; there comes a point where it's cheaper to replace older hardware with new, more energy efficient hardware.
Thanks again. BTW, are you still climbing in the Lakes? I moved back up there 5 years ago, then moved again last year... never seem to be able to stay there!
You must have mixed me up with someone else there. I wish I could go walking, but I've been a powerchair user since 1997 due to a neuromuscular condition. Nevertheless, I hope that whoever you mixed me up with is still enjoying the great outdoors, also that you get back to the Lakes sometime.