I Quit Using pfsense

[System Error Message]

the first gen iseries 32nm has AES-NI, so that means it will be the minimum requirement for pfsense. On AMD side that will be the bulldozer.

 

[coxhaus]

And pfSense - flexibility is what it is, and sometimes at the cost of usability... done right - it's a high performance package...

I disagree as it does not seem high performance to me and there is not just one way to setup networking. So done right has no meaning.

 

[Cake]

Does it make sense to have a box without Intel's V-Pro tech (IME - management engine) for pfsense/opnsense. Seems like it could be a issue for a big corp. and to have such a overlooked backdoor on your router/firewall. AMD also does something very similar. I haven't seen it discussed much, so maybe its not a issue. The J1900 cpu does not have it as far as I know, it is also missing AES instructions.

 

[System Error Message]

Does it make sense to have a box without Intel's V-Pro tech (IME - management engine) for pfsense/opnsense. Seems like it could be a issue for a big corp. and to have such a overlooked backdoor on your router/firewall. AMD also does something very similar. I haven't seen it discussed much, so maybe its not a issue. The J1900 cpu does not have it as far as I know, it is also missing AES instructions.

nope. You can turn off VPRO.

 

[Nullity]

I disagree as it does not seem high performance to me and there is not just one way to setup networking. So done right has no meaning.

Whether pfSense, or any reputable system, is "high performance" or "better" is hard to quantify. Similarly, it's hard to objectively criticize without some concrete, repeatable examples of failure.

I personally chose a FreeBSD-derived OS for networking purposes because I think it has he most dependable/reputable TCP/IP stack.

I prefer certain aspects of different systems, but I hesitate to criticize a system for not being my preference.


All systems are simultaneously horrible and great. Without details, it's just a never-ending pissing match with no possible conclusion.

 

[sfx2000]

I disagree as it does not seem high performance to me and there is not just one way to setup networking. So done right has no meaning.

There's an ongoing bug with unbound and dnsmasq and resolution across multiple interfaces - wonder if that is what was impacting your performance - it's not common, but when it bites, it bites hard...

 

[sfx2000]

nope. You can turn off VPRO.

Not in all platforms - choose carefully there...

 

[sfx2000]

Whether pfSense, or any reputable system, is "high performance" or "better" is hard to quantify. Similarly, it's hard to objectively criticize without some concrete, repeatable examples of failure.

And in a community like snbforums - there's a fair amount of subjective opinion - and rightly so - either it works or not. Some of those opinions are more founded than others..

Objectively - depends on needs and requirements - and a solution will be found - might not be pfSense. That being said - pfSense has a good track record, as does FreeBSD - and Jim T. has done a lot to bring FreeBSD into the ARM space, sponsoring projects for the ARM port.

I personally chose a FreeBSD-derived OS for networking purposes because I think it has he most dependable/reputable TCP/IP stack.

There's a fair amount of commercial routers that have foundations on BSD in general... and Linux is fairly inspired by developments there - that being said - Linux does stand on it's own development wise..

I prefer certain aspects of different systems, but I hesitate to criticize a system for not being my preference.

All systems are simultaneously horrible and great. Without details, it's just a never-ending pissing match with no possible conclusion.

Hehe - for some it's love, for others, it's a big ball of hate... but this just is...

As long as the packets flow - it's all good...

 

[coxhaus]

If the packets flow slow then it is no good.

I don't run multiple interfaces in pfsense. I have one "in" interface and one "out" interface. It does not get any simpler than that.

Whether it is a bug or not it is a problem with pfsense affecting the performance.

 

[sfx2000]

If the packets flow slow then it is no good.

I don't run multiple interfaces in pfsense. I have one "in" interface and one "out" interface. It does not get any simpler than that.

Whether it is a bug or not it is a problem with pfsense affecting the performance.

Based on earlier comments - it was more about DNS issues with pfSense, and that's understood... not that the packets themselves were slow, just the lookups, and that's a big deal - understood.

DNS Resolver vs. DNS Forwarder - and dnsmasq and unbound, and the complexities there... get it right, and performance is great - get it wrong, and well - a lot of frustration and posts on snbforums that suggest that pfSense isn't the right answer.

All good - hope your RV*** device works well.

 

[VisionxOrb]

For what its worth, Im trying out opnsense on what was my pfsense box, performance so far has been fantastic although I don't find the GUI as easy to use.

Had to install it via DVD as the memstick images are efi only. Tried to dvd iso to memstick but rufus and and win7DLtool complained.

 

[Nullity]

If the packets flow slow then it is no good.

I don't run multiple interfaces in pfsense. I have one "in" interface and one "out" interface. It does not get any simpler than that.

Whether it is a bug or not it is a problem with pfsense affecting the performance.

It's no good for you. I understand that some things "just work" for certain cituations but I think it's dangerous, especially for an influential person, to declare something as "no good" simply because you didn't have a good experience.

If you have details (like sfx mentioned) then I can fully support your position, but if not... how does that help anybody? Linux sucks, Windows sucks, ARM sucks... all true but simultaneously untrue without details.

I often choose the device that "just works" but I hesitate to declare the non-working device as crap, since I am usually just too lazy to trouble-shoot and solve my problem with said device.

 

[sfx2000]

If the packets flow slow then it is no good.

I don't run multiple interfaces in pfsense. I have one "in" interface and one "out" interface. It does not get any simpler than that.

Whether it is a bug or not it is a problem with pfsense affecting the performance.

All good man... if the RV works - it's a good device - maybe pfSense was overkill or not, depends on the use case.

Still think maybe there's issues with DNSResolver vs. DNSForwarder in your case - but takes some time/effort to debug, and that's a challenge for something that is still free to download and install.

 

[Cake]

nope. You can turn off VPRO.

I'm not so sure. I read that ME is part of the boot process. Anyways it has been in the news lately.
https://twitter.com/h0t_max/status/928269320064450560

A good read here

 

[sfx2000]

Does it make sense to have a box without Intel's V-Pro tech (IME - management engine) for pfsense/opnsense. Seems like it could be a issue for a big corp. and to have such a overlooked backdoor on your router/firewall. AMD also does something very similar. I haven't seen it discussed much, so maybe its not a issue. The J1900 cpu does not have it as far as I know, it is also missing AES instructions.

There's some concern with the management engines inside more recent Intel chipsets - and while yes, V-Pro can be disabled in UEFI/BIOS for some machines, the ME is still running as it basically has to.

Intel recently disclosed a number of critical issues with ME, and has released code updates to fix them - challenge is that the OEM's have to integrate those changes into firmware and release updates...

@Cake - Baytrail does not have ME, but has something similar, so check for updates.

UEFI runs at a very low level - before the bootloader, so it's actually more privileged than admin - and this risk is for any OS that runs on Intel x86/x86-64 platforms with recent chipsets that have ME (or similar elements). Many of these are edge cases, needing physical access for some chipsets, but newer ones (if I recall Broadwell and later) have a USB stub in UEFI that can be accessed via userland, and this is a huge problem.

 

[Xentrk]

I've been using both DNS Resolver and DNS Forwarder on pfSense - one of the nice things about pfSense is the flexibility of assigning ranges and DNS per VLAN, and reduce the risk of DNS leakage when using OpenVPN or L2TP/IPSec.

Somebody posted a very good walk-thru on pfSense setup and configuration with multiple VLAN's and VPN setups.

https://nguvu.org/pfsense/pfsense-baseline-setup/

I can understand though why people are looking to migrate out of pfSense when using repurposed machines - pfSense 2.4 requires a 64bit CPU, and pfSense 2.5 is going to require AES-NI along with 64-bit support - which on older builds, this can be a problem.

Thank you for posting that link. I now have it book marked. I never came across those instructions before in my pfSense searches. I had to make a few passes to have it all sink in. I don't use VLANS. But I can think of a use case or two for this now after reading the article.

 

[coxhaus]

Still think maybe there's issues with DNSResolver vs. DNSForwarder in your case - but takes some time/effort to debug, and that's a challenge for something that is still free to download and install.

This problem did not exist when I first installed pfsense as I tested it thoroughly. The problem came about with the pfsense updates. I make no changes to my routers as my layer 3 switch is where I make changes since it is my real router for my local network.