To 2.5.0 or not ? that is the question :)
-
What is your WAN type?
How is it failing? The actual link goes down? Not pulling an IP?
Steve
-
@stephenw10
EVERYTHING, EXCEPT the LAN Traffic Monitor works.
I changed the time on my Win10 box, it has the Chrome interface to the pfSense box, and the WAN Traffic Monitor recovered, now works. That was strange.
LAN Traffic Monitor is still NOT working.
Though, worked great in the previous release.
Tried Firefox, still no go. -
Like the traffic graphs? Can we see a screenshot?
We have seen problems there before with a bad timezone.
Steve
-
-
Ah, yes sorry I conflated some topics there
Hmm, do you see the interface stats incrementing for LAN? What driver is it?
Steve
-
@stephenw10
Yes, Interface Statistics is updating.Intel OEM I350-T4
dmesg shows it is using:
igb0: <Intel(R) PRO/1000 PCI-Express Network Driver> mem 0xf7b00000-0xf7bfffff,0xf7c0c000-0xf7c0ffff irq 16 at device 0.0 on pci2Hmm, I can't remember what driver the former release used...
-
@buggz I'm facing issues using VLAN's with v2.5.0, where all VLAN tagged interfaces reports some output errors. Seems it has something to do with the 'igb' driver and IPv6. It doesn't affect the performance in any noticeable way, but it wasn't present in v2.4.5. After some research, it seems to do with the Intel 'igb' driver bundled with FreeBSD 12.2-STABLE. Following is a link to others facing the same problem:
https://github.com/opnsense/src/issues/74
I'm not experiencing problems with the traffic graphs, but maybe this got something to do with it. Hope this gets fixed in the next release.
-
Hmm, that doesn't seem to be generally the case. I have a whole bunch of boxes with igb NICs and VLANs and haven't noticed anything . Of course now I'm going to go digging....
But that seems unlikely to be related to this graphing issue.
Steve
-
Wow, and now LAN Traffic Graph magically works for the first time.
I did update ntopng to the latest, but it didn't work then.
Does now on reboot. -
Still in 2.5.0 or 2.5.1-RC snapshots?
Steve
-
Is wireguard being pulled from 2.5.1? I wasn’t able to update to latest RC (2.5.1.r.20210320.0824 ) due to having 'wireguard tunnels enabled'. I understood it was being pulled from the kernel until the version Jason is currently developing is integrated into FreeBSD (13.2?), but I assumed the Netgate funded version would remain in pfSense until that swap could be made as the security implications were only a concern if admin access had already been compromised?
0) Logout (SSH only) 9) pfTop 1) Assign Interfaces 10) Filter Logs 2) Set interface(s) IP address 11) Restart webConfigurator 3) Reset webConfigurator password 12) PHP shell + pfSense tools 4) Reset to factory defaults 13) Update from console 5) Reboot system 14) Disable Secure Shell (sshd) 6) Halt system 15) Restore recent configuration 7) Ping host 16) Restart PHP-FPM 8) Shell Enter an option: 13 ERROR: There are WireGuard tunnels enabled on your config. Please remove or disable them before proceed. -
@stephenw10
2.5.0 for me. -
I give up, now broken again.
I wont report no more, as I am certain everyone, and me, is tired of hearing from a "whiner". -
i agree. i think shouldnt give up wireguard now. this bug main is kernel, linux kernel report fixed this. Don't give up eating because of choking.
-
If I may suggest for users who experienced bugs, just do a clean install 2.5.0 or you could try 2.5.1 (for testing purpose only) please note no WireGuard:
https://snapshots.netgate.com/amd64/pfSense_RELENG_2_5_1/installer/
Then do re-configure from the scratch.About WireGuard, in my opinion there was some miscommunication between Netgate team and Jason A. Donenfeld (WireGuard). I really hope they would come to some agreement that benefit for their users and not waiting until June.
Here is a full statement from Jason A. Donenfeld :
Hi everybody, I’m pleased to announce that WireGuard now runs inside the FreeBSD kernel, with a driver called if_wg. It has full support of wg(8) and wg-quick(8) [5], as well as general integration into FreeBSD userland. Performance should be decent. The implementation in FreeBSD’s main branch should pretty much work, though it’s something of a so-so work in progress. To learn what I mean there, read on… Sometime ago, a popular firewall vendor tasked a developer with writing a WireGuard implementation for FreeBSD. They didn’t bother reaching out to the project. That’s okay, I figured, I’ll reach out and see if I can help and coordinate. What followed over the next year was a series of poor communications – messages unanswered, code reviews ignored, that kind of thing. Usually collaborations I’ve had with others have been full of excitement, but it just didn’t work out here. In the few discussions we were able to have, I did get across some key points, like, “you’ll save a bunch of time if you use the OpenBSD code as a starting point.” But mostly it seemed like a stop-and-go effort that the WireGuard project didn’t have much to do with. Then, at some point, whatever code laying around got merged into the FreeBSD tree and the developer tasked with writing it moved on. Fortunately, two weeks before FreeBSD 13.0 was due to be released, FreeBSD core developer Kyle Evans emailed the list about integrating wireguard-tools (wg(8) and such). In the ensuing discussion I mentioned that we really need to get the actual if_wg kernel implementation up to snuff. We took the conversation to IRC, and agreed that we should work on figuring out what to do before the release date. At the same time, Matt Dunwoodie, who worked on the OpenBSD implementation, also took a look at what had become of that implementation in FreeBSD. Over the next week, the three of us dug in and completely reworked the implementation from top to bottom, each one of us pushing commits and taking passes through the code to ensure correctness. The result was [6]. It was an incredible effort. The collaboration was very fast paced and exciting. Matt and Kyle are terrific programmers and fun to work with too. The first step was assessing the current state of the code the previous developer had dumped into the tree. It was not pretty. I imagined strange Internet voices jeering, “this is what gives C a bad name!” There were random sleeps added to “fix” race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren’t careful when they write C. Or, more simply, it seems typical of what happens when code ships that wasn’t meant to. It was essentially an incomplete half-baked implementation – nothing close to something anybody would want on a production machine. Matt had to talk me out of just insisting they pull the code entirely, and rework it more slowly and carefully for the next release cycle. And he was right: nobody would have agreed to do that, and it would only have fostered frustration from folks genuinely enthusiastic about if_wg. So our one and only option was to iteratively improve it as fast as we could during the two weeks before release, and try to make it as simple and close as possible to OpenBSD so that we could benefit from the previous analysis done there. With that as our mission, we set out auditing and rewriting code. One curious thing of note is that there were 40,000 lines of optimized crypto implementations pulled out of the Linux kernel compat module but not really wired up correctly, and mangled beyond repair with mazes of Linux→FreeBSD ifdefs. I wound up replacing this with an 1,800 line file, crypto.c [1], containing all of the cryptographic primitives needed to implement WireGuard. Aside from its place in the FreeBSD story, this is kind of neat in its own right: these are simple, but fast enough, reference implementations. It’s not deliberately tiny or obfuscated like TweetNaCl is, yet is still just a single file, and the Curve25519 field arithmetic in it is formally verified. Maybe other projects will find use for it. Future releases will hopefully get rid of crypto.c and hook into FreeBSD’s already existing optimized implementations [4], which should give a nice performance boost, but given the time crunch, having something boring, safe, and simple seemed like the way to go. We reduced the project structure down to four C files – the aforementioned crypto.c, two files copied verbatim from OpenBSD – wg_noise.c and wg_cookie.c – and if_wg.c, the actual interface device driver implementation and protocol logic. The IPC interface was reworked as well, and wg(8) in the wireguard-tools package grew support for it (also rewritten from the original attempt). The three of us spent countless hours across three time zones auditing state machine logic, running trials, and generally trying to get this working and workable. There are now even a few automated tests! I think we’ve mostly succeeded in producing something that behaves like WireGuard. The net result certainly isn’t perfect, though – the Linux and OpenBSD implementations were long, careful, slow projects by comparison – but it is at least a base on which to build and improve over time. Going forward, I think there’ll be additional systems coding issues to work out – locking, lifetimes, races, and that sort of thing. But now that there’s at least a stable base, developers can work out remaining issues incrementally. But perhaps this is a good moment to step back and ask how we got here, and what WireGuard itself really is. Traditionally, network protocols are specified in a document of protocol behaviors. Then different organizations implement that specification. Then everybody interoperates and all goes well. In practice, it often doesn’t go well (see IPsec woes), but this at least has been the traditional way of doing this on the Internet, and in some ways it works. But that is not the approach taken by the WireGuard project. In contrast, WireGuard is both a protocol and a set of implementations, implemented with a particular set of security and safety techniques. That’s a radical departure from the traditional model, and one surely to raise some grumbles amongst graybeards. But I believe this is a necessary and beneficial quality for having the types of high assurance software that is needed for core Internet security infrastructure. When you use WireGuard, you’re not just using some protocol that is capable of producing packets that are legible by others. You’re also using an implementation that’s been designed to avoid security pitfalls, and that provides interfaces for using it that mitigate footguns. In that way, the WireGuard project is more expansive than a mere protocol project or a mere software project or a mere cryptography project or a mere specification project or a mere interface project. It combines all of those things into a single unified approach. (For this same reason, the original WireGuard paper [2] has been difficult for folks to categorize. Is this a systems paper? A networking paper? A crypto paper?) Because of that, I think this was an understandable predicament. After all, why shouldn’t a company be able to task a developer with writing some ring-0 WireGuard code in C? And why does it matter to me whether the code is garbage if it can at least produce protocol packets? The reason is that the WireGuard project’s mission is wider than that. We deeply care about code quality and implementation particulars. While we now have the FreeBSD code in a maintainable state, there are other projects too that could use some attention from us. Looking forward, for example, we hope to be able to lend a hand similarly to the NetBSD developers soon to help them finish their implementation; this is long overdue on my part, and I owe them some time and energy there. And I hope that others don’t hesitate to email the list asking for collaboration. This kind of thing is, of course, one of the reasons that the project as an organization exists. To return to the primary announcement, I had originally hoped to say that this would be shipping for 13.0, and have some instructions for setup there, but unfortunately, and contrary to our plans, it looks exceedingly likely that given the grave issues we found in the existing code, they’ll in the end just disable the module from the release, and revisit for 13.1, rather than merging our fixes a few short days before the release. That’s a bit of a bummer, given how hard we worked to get things done in the time crunch, but it’s also probably a very wise decision that takes some courage to make, and this will give us more time to really get this rock solid for 13.1. As well, hopefully we’ll have backport modules for the 13.0 and 12.y release, making it as available as possible. Kyle or I will update the list when we’ve got a standalone backport module ready, with instructions, as well as updating [3] per usual. There’s also ongoing work to integrate WireGuard interface setup into rc, and hopefully that will land during the the next release window, as well as the aforementioned improvements to optimized crypto and systems issues. Enjoy, Jason
