Re: [pfSense] Nat between vlans
I have created a similar network and this is exactly what I do. Not translating addresses greatly simplifies any DNS configuration where you give names to all of your devices, too. On 03/30/2018 12:41 PM, Steve Yates wrote: > Wouldn't it be easier to just create a firewall rule to allow the Guest VLAN > to the printer IP:port? It would be the same thing...they can only access > that IP:port? > > -- > > Steve Yates > ITS, Inc. > > -Original Message- > From: List On Behalf Of Yilmaz Bilgili > Sent: Friday, March 30, 2018 10:33 AM > To: list@lists.pfsense.org > Subject: [pfSense] Nat between vlans > > Dear all, > > I have a multi vlan setup and I want to give access to my printer on > corp vlan from guest vlan. There is no access from guest vlan to corp > vlan at the moment (and will never be). Can I use an IP address from > guest vlan and nat it to printer's IP address on the corp network? My > box is an up to date 2.4.2. > > Thanks in advance. > > Best regards. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Configs or hardware?
ld like to ask: is this unsolvable without hardware acceleration? > I side with Mr. Parker here. How long does a project have to wait before > demanding certain features for future revisions, assuming it gives adequate > warning to the existing and future users of that project? I’ll note that you > didn’t answer his question. I never answered the question because I did not think the answer or the question was relevant. Until today, it was my understanding that AES-NI was simply to improve throughput of applications utilizing AES. I had previously not been presented with anything to indicate that it helps with any security issues such as the timing attacks discussed here. However, to address the question in some way, I do agree that features like this should be taken advantage of as much as possible. However, unlike other advances such as x86 to x86_64, AES-NI does not create any new functionality that did not already exist. Until the security benefits have been presented, I did not see any use case where AES-NI would be necessary over the software implementation. I would like to point out that AES-NI is not "in everything" since 2008 as previously indicated. While I understand these may not fall under the "all major x64 processors" category, Intel has launched CPUs without AES-NI within the past couple of years. See: https://ark.intel.com/Search/FeatureFilter?productType=processors&AESTech=false&BornOnDate=Q4%2716 > And, finally, Mr. Volotinen called it exactly. We announced this in May > last year, so that those buying hardware in the now would know about the > future requirements. Anyone buying hardware now can make an informed > decision as to if they want to buy or otherwise obtain a platform for pfSense > that supports AES-NI, or not. Either will work as long as they are running a > 2.4.x release of pfSense, and, as above, 2.4 has a plan that includes support > until, at least, 2020. This is acceptable. It just also just sucks, and I understand it must be faced. This is, however, beyond just replacing some networking equipment, as I have to replace my primary VM host due to CPU replacements supporting AES-NI not existing. Before knowing that the AES-NI requirement was to address the timing attack, I felt as if I have to pay for new hardware due to Netgate not "wanting" non-AES-NI AES implementations being utilized. Until this, I have not exactly had software support issues with even this aging hardware. I understand that a lot of people are effectively threatening to switch to OpnSense due to this, but I fear that I will *have to* if I can't replace my hardware by the time support for software AES ends entirely. See: https://ark.intel.com/Search/FeatureFilter?productType=processors&SocketsSupported=LGA771&AESTech=true I thank you for addressing this with me. I appreciate your conduct with me despite my comment. > Jim > >> On Feb 15, 2018, at 2:11 PM, Kyle Marek wrote: >> >> I think you're missing the point that software support exists; pfSense >> supports software AES *now*, and this is being removed. New technology >> is cool; things not working anymore is not. >> >> Anyway, what are are other projects such as the TLS libraries doing >> about this? Is hardware acceleration really the only solution? >> >> On 02/15/2018 01:39 PM, Walter Parker wrote: >>> Well, both Intel and AMD starting shipping the AES-NI instructions 8 years >>> ago... >>> >>> How long does a project need to wait before it can require a feature found >>> on all major x64 processors? Waiting 8-9 years seems reasonable to me. >>> >>> Given the fact that the project is only supporting 64-bit and suggests >>> using a modern processor this requirement should be a non issue for most >>> users. >>> >>> The only place where the AES-NI instructions are not found is in a small >>> number of embedded/dev boards using older Celeron processors. >>> >>> >>> Walter >>> >>> On Thu, Feb 15, 2018 at 9:37 AM, Kyle Marek wrote: >>> >>>> This is silly. I shouldn't have to replace my hardware to support a >>>> feature I will not use... >>>> >>>> I shame Netgate for such an artificial limitation... >>>> >>>> Thank you for the information. >>>> >>>> On 02/15/2018 12:20 PM, Eero Volotinen wrote: >>>>> Well: >>>>> >>>>> https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html so we are >>>> talking >>>>> about 2.5 not 3.x ? >>>>> >>>>> "While we’re not revealing the extent of our plans, we do want to give >>
Re: [pfSense] Configs or hardware?
I think you're missing the point that software support exists; pfSense supports software AES *now*, and this is being removed. New technology is cool; things not working anymore is not. Anyway, what are are other projects such as the TLS libraries doing about this? Is hardware acceleration really the only solution? On 02/15/2018 01:39 PM, Walter Parker wrote: > Well, both Intel and AMD starting shipping the AES-NI instructions 8 years > ago... > > How long does a project need to wait before it can require a feature found > on all major x64 processors? Waiting 8-9 years seems reasonable to me. > > Given the fact that the project is only supporting 64-bit and suggests > using a modern processor this requirement should be a non issue for most > users. > > The only place where the AES-NI instructions are not found is in a small > number of embedded/dev boards using older Celeron processors. > > > Walter > > On Thu, Feb 15, 2018 at 9:37 AM, Kyle Marek wrote: > >> This is silly. I shouldn't have to replace my hardware to support a >> feature I will not use... >> >> I shame Netgate for such an artificial limitation... >> >> Thank you for the information. >> >> On 02/15/2018 12:20 PM, Eero Volotinen wrote: >>> Well: >>> >>> https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html so we are >> talking >>> about 2.5 not 3.x ? >>> >>> "While we’re not revealing the extent of our plans, we do want to give >>> early notice that, in order to support the increased cryptographic loads >>> that we see as part of pfSense verison 2.5, pfSense Community Edition >>> version 2.5 will include a requirement that the CPU supports AES-NI. On >>> ARM-based systems, the additional load from AES operations will be >>> offloaded to on-die cryptographic accelerators, such as the one found on >>> our SG-1000 <https://www.netgate.com/products/sg-1000.html>. ARM v8 CPUs >>> include instructions like AES-NI >>> <https://www.arm.com/files/downloads/ARMv8_Architecture.pdf> that can be >>> used to increase performance of the AES algorithm on these platforms." >>> >>> >>> Eero >>> >>> On Thu, Feb 15, 2018 at 7:18 PM, Edwin Pers wrote: >>> >>>> I believe I read somewhere that the new version that requires aes-ni >> will >>>> be 3.x, and they plan to continue the 2.x line alongside it, as 3.x >> will be >>>> a major rewrite >>>> >>>> >>>> -Ed >>>> >>>> -Original Message- >>>> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Eero >>>> Volotinen >>>> Sent: Thursday, February 15, 2018 12:14 PM >>>> To: Kyle Marek >>>> Cc: pfSense Support and Discussion Mailing List >>> Subject: Re: [pfSense] Configs or hardware? >>>> >>>> Well. Next version of pfsense (2.5) will not install into hardware that >>>> does not support AES-NI, so buying such hardware is not wise ? >>>> >>>> Eero >>>> >>>> >>>> ___ >>>> pfSense mailing list >>>> https://lists.pfsense.org/mailman/listinfo/list >>>> Support the project with Gold! https://pfsense.org/gold >>>> >>> ___ >>> pfSense mailing list >>> https://lists.pfsense.org/mailman/listinfo/list >>> Support the project with Gold! https://pfsense.org/gold >> ___ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Configs or hardware?
This is silly. I shouldn't have to replace my hardware to support a feature I will not use... I shame Netgate for such an artificial limitation... Thank you for the information. On 02/15/2018 12:20 PM, Eero Volotinen wrote: > Well: > > https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html so we are talking > about 2.5 not 3.x ? > > "While we’re not revealing the extent of our plans, we do want to give > early notice that, in order to support the increased cryptographic loads > that we see as part of pfSense verison 2.5, pfSense Community Edition > version 2.5 will include a requirement that the CPU supports AES-NI. On > ARM-based systems, the additional load from AES operations will be > offloaded to on-die cryptographic accelerators, such as the one found on > our SG-1000 <https://www.netgate.com/products/sg-1000.html>. ARM v8 CPUs > include instructions like AES-NI > <https://www.arm.com/files/downloads/ARMv8_Architecture.pdf> that can be > used to increase performance of the AES algorithm on these platforms." > > > Eero > > On Thu, Feb 15, 2018 at 7:18 PM, Edwin Pers wrote: > >> I believe I read somewhere that the new version that requires aes-ni will >> be 3.x, and they plan to continue the 2.x line alongside it, as 3.x will be >> a major rewrite >> >> >> -Ed >> >> -Original Message- >> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Eero >> Volotinen >> Sent: Thursday, February 15, 2018 12:14 PM >> To: Kyle Marek >> Cc: pfSense Support and Discussion Mailing List >> Subject: Re: [pfSense] Configs or hardware? >> >> Well. Next version of pfsense (2.5) will not install into hardware that >> does not support AES-NI, so buying such hardware is not wise ? >> >> Eero >> >> >> ___ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold >> > ___ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Configs or hardware?
I have not had such an issue. Using 2.4.2 with System Information widget saying "AES-NI CPU Crypto: No". On 02/15/2018 11:55 AM, Eero Volotinen wrote: > Please note that next pfsense will not install hardware that is not > supporting aes-ni? > > Eero > > On Thu, Feb 15, 2018 at 6:37 PM, Kyle Marek wrote: > >> This board does round-up gigabit (something like 976 Mb/s) in both >> directions on all 4 interfaces: https://www.amazon.com/dp/B00XNR4HE2/ >> >> The key for me here was the interrupt coalescence of these particular >> Intel NICs. A very similar board with Broadcom NICs that lacked this >> feature maxed out the interrupt handler's CPU usage on Linux when >> surpassing the forwarding of a single 1 Gb/s stream (1 Gb/s in on one >> interface; 1 Gb/s out on another). >> >> A potential downside is no AES-NI, which will affect any AES-utilizing >> VPNs that you need to operate at gigabit speeds. I have no benchmarks at >> the moment but can measure if this is necessary for you. >> >> On 02/15/2018 09:14 AM, Michael Munger wrote: >>> TL; DR. >>> >>> On 1Gbps downloads, our pfSense firewalls are performing poorly with >>> speed tests of ~400Mbps. It's either pfSense configs (not likely) or the >>> hardware (more likely). I do not want to buy a commercial box. For our >>> corporate network, we use HP DL360s, so zero problem there.I need >>> something that is the size of a router, but can do 1Gbps with pfSense. >>> >>> Who's got working configs / hardware combos that do 1Gbps easily? >>> >>> Background. >>> >>> I've been using Alix boards (APU1D4 as of late). The problem is: these >>> boards seem to top out at 400Mbps download. I have several clients who >>> have gigabit fiber connections, and they have been complaining to the >>> ISP that their service is slow. When they connect to the modem directly, >>> they get 1G download. When they go through the pfSense firewall we put >>> together using these Alix boards from PC engines, it drops to ~400Mbps. >>> >>> There are several competing "router boards" (Microtik and the like), but >>> I have zero experience with them, I don't know if they will run pfSense >>> or if they will do the speed. The Alix + pfSense combo has been GREAT >>> for many years. If I change to something else, I don't want to go >>> through growing pains since I figure this is a solved problem, and >>> someone on this list knows / has a recommendation. >> ___ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold >> > ___ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Configs or hardware?
This board does round-up gigabit (something like 976 Mb/s) in both directions on all 4 interfaces: https://www.amazon.com/dp/B00XNR4HE2/ The key for me here was the interrupt coalescence of these particular Intel NICs. A very similar board with Broadcom NICs that lacked this feature maxed out the interrupt handler's CPU usage on Linux when surpassing the forwarding of a single 1 Gb/s stream (1 Gb/s in on one interface; 1 Gb/s out on another). A potential downside is no AES-NI, which will affect any AES-utilizing VPNs that you need to operate at gigabit speeds. I have no benchmarks at the moment but can measure if this is necessary for you. On 02/15/2018 09:14 AM, Michael Munger wrote: > TL; DR. > > On 1Gbps downloads, our pfSense firewalls are performing poorly with > speed tests of ~400Mbps. It's either pfSense configs (not likely) or the > hardware (more likely). I do not want to buy a commercial box. For our > corporate network, we use HP DL360s, so zero problem there.I need > something that is the size of a router, but can do 1Gbps with pfSense. > > Who's got working configs / hardware combos that do 1Gbps easily? > > Background. > > I've been using Alix boards (APU1D4 as of late). The problem is: these > boards seem to top out at 400Mbps download. I have several clients who > have gigabit fiber connections, and they have been complaining to the > ISP that their service is slow. When they connect to the modem directly, > they get 1G download. When they go through the pfSense firewall we put > together using these Alix boards from PC engines, it drops to ~400Mbps. > > There are several competing "router boards" (Microtik and the like), but > I have zero experience with them, I don't know if they will run pfSense > or if they will do the speed. The Alix + pfSense combo has been GREAT > for many years. If I change to something else, I don't want to go > through growing pains since I figure this is a solved problem, and > someone on this list knows / has a recommendation. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign • The Register - patch to pfsense?
No speculative execution on your 32-bit machine? On 01/16/2018 03:02 PM, Peder Rovelstad wrote: > Back to my x86 Via box! :/ Just when my Hyper-V x64 was really tuned... > > -Original Message- > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Rainer Duffner > Sent: Tuesday, January 9, 2018 5:32 PM > To: pfSense Support and Discussion Mailing List > Subject: Re: [pfSense] 'Kernel memory leaking' Intel processor design flaw > forces Linux, Windows redesign • The Register - patch to pfsense? > > > >> Am 10.01.2018 um 00:14 schrieb Kyle Marek : >> >> This contradicts the majority of the purpose of virtualization. > > Interesting that you bring it up…. > > I give you Theo de Raadt in late 2007: > > > https://marc.info/?l=openbsd-misc&m=119318909016582 > <https://marc.info/?l=openbsd-misc&m=119318909016582> > > > ;-) > > > > Meanwhile, Netgate has published an updated statement: > > https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html > <https://www.netgate.com/blog/an-update-on-meltdown-and-spectre.html> ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign • The Register - patch to pfsense?
On 01/09/2018 05:58 PM, Gé Weijers wrote: > On Wed, Jan 3, 2018 at 2:32 PM, Walter Parker wrote: > >> On Wed, Jan 3, 2018 at 2:25 PM, Steve Yates wrote: >> >>> I'm not a developer but I would think it's dependent on FreeBSD releasing >>> the update, plus testing by pfSense/Netgate. However, I would think >>> there's not much concern with PCs running pfSense, since raw code would >> not >>> normally be running on the pfSense box...? > Agreed, if someone manages to run malicious code on your pfSense box you > have bigger problems. I disagree. The fact that user processes can gain kernel-level access *is* the bigger problem. A buffer overflow affecting a process running as _dhcp would not otherwise result in such a severe issue. > HOWEVER: running pfSense as a virtual machine may not be the best idea if > you do not have full control over the other VMs running on the same > hardware. This contradicts the majority of the purpose of virtualization. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
