In reply to a post by David_W:

Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.

Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.

Saying that I currently use this setup as I am too stingy to get a second nic for my Linux router box.

I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.

In reply to a post by legume:

In reply to a post by David_W:

Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.

Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.

The link between the pfSense box and the VDSL2 bridge uses a dedicated VLAN in my system, completely isolating that traffic from the rest of the network. Moreover, my switches use IGMP (for IPv4) and MLD (for IPv6) snooping, so multicast traffic is only sent to the port(s) that have joined the relevant multicast group. This stops a lot of pointless multicast traffic being sent over Wi-Fi. I don't have multicast television anyway.

In reply to a post by legume:

I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.

FreeBSD is exactly the same as Linux - you have to set the MTU of the parent interface of the PPPoE connection to at least 1508 (1500 plus 8 for the PPPoE overhead) before you can use a 1500 byte MTU for the PPPoE connection. However, pfSense handles this complexity automatically - I know, because I wrote the code!

Sounds more like traffic is hitting your router from the WAN + borderline faulty router.

Over what period of time did it send and receive the data?

In reply to a post by David_W:

In reply to a post by legume:

In reply to a post by David_W:

Both the Openreach modems will work. If you have a jumbo capable NIC on your WAN interface, you can set MTU 1500 on the WAN interface and pfSense will use RFC 4638 (N.B. Intel NICs and possibly other brands only work with jumbo frames with a Gigabit link, so you might need to put a Gigabit switch between the WAN NIC and the modem). IPv6 should be supported if SSE are providing IPv6.

Your modem will eat any multicast, reducing upstream bandwidth if you don't isolate it from the LAN. Not so much of an issue if you don't have any bulk multicast around. If you were to have an ISP with a multicast TV product, there is a warning in the SINS that suggest isolating WAN/LAN with igmpproxy as some cabs have limited mac learning so there could be issues changing/channels starting streams if lots of devices are seen.

The link between the pfSense box and the VDSL2 bridge uses a dedicated VLAN in my system, completely isolating that traffic from the rest of the network. Moreover, my switches use IGMP (for IPv4) and MLD (for IPv6) snooping, so multicast traffic is only sent to the port(s) that have joined the relevant multicast group. This stops a lot of pointless multicast traffic being sent over Wi-Fi. I don't have multicast television anyway.

Ahh, fair enough, you have a "proper" setup with a clever switch. The OP may have had a dumb switch so getting the "eats multicast" issue out was still worth while.

On not having multicast TV - I don't have it either. but my ISP = Plusnet do sell it. I don't know if that's relevant or if this applies to anyone with a BTW ISP. I can get multicast TV to hit the wan eg, this promo channel is unencrypted.

rtp://234.81.130.4:5802

In reply to a post by David_W:

In reply to a post by legume:

I guess BSD is different from Linux for baby jumbos - my pppd won't try to use them unless the mtu on the nic associated with the pppoe is >= 1508. Easy if it it's a gig nic, may need hack for old nics. I used to use a 17 year old PIII box and managed to hack the driver so both onboard nic and a dual port ancient compaq PCI nic would work with 1508.

FreeBSD is exactly the same as Linux - you have to set the MTU of the parent interface of the PPPoE connection to at least 1508 (1500 plus 8 for the PPPoE overhead) before you can use a 1500 byte MTU for the PPPoE connection. However, pfSense handles this complexity automatically - I know, because I wrote the code!

Nice. Strange Intel gig nics don't play - surely there's a hack just waiting to happen there. I don't have a gig intel so can't say what its like on Linux.

All three (100mbit) nics on my old setup used intel e100.c and the hack was surprisingly easy - just added 8 in a few places throughout the code. Of course it was just for me and I fully expected it may crash and burn - but it didn't.

In reply to a post by alewis:

In reply to a post by David_W:

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.

In reply to a post by alewis:

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.

In reply to a post by alewis:

In reply to a post by David_W:

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.

In reply to a post by alewis:

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.