OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: RouterGuy2019 on September 11, 2020, 01:54:46 pm
-
I have been watching this forum since 20.7 came out, I want to upgrade but all I am seeing is problems. Is anyone having success with 20.7 (aka problem free after upgrade)? The post that has me most concerned is this one about slow WAN after upgrade...
https://forum.opnsense.org/index.php?topic=18450.60
Is there some common thread with the people having this issue or is it totally random?
I appreciate any feedback.
Thanks in Advance, RouterGuy2019
-
I have no problems with 20.7 (igb network hardware, no IDS/IPS).
You also need to keep in mind that the people who post here are the ones experiencing issues. The people that don't have problems don't post here, so reading this forum doesn't give you a fair view on success/failure rate ;)
-
I have a problem with traffic graphs not showing any data where IDS/IPS is used on the interface. Turned off IDS/IPS on WAN (still enabled on LAN) so graphs at least show WAN traffic. Other than that, I have no issues. I haven't noticed any performance issues or increased CPU usage. Intel i350 network hardware and 900Mbps up and down.
-
No Problems at any of my 7 Appliances. Mostly igb, and mlenx Cards.
Its by nature, that you will find only problems in forums. People with smooth running installations will probably not look here and write something ;-)
-
Some problems with IPv6 (radvd) on two systems running 20.7.
The other installations will be running at 20.1 until this problem ist solved.
I think IPv6 is essential and to few people are using/testing IPv6.
Bye
Robert
-
I had problems after upgrading with my ipv6 setup. But did a clean reinstall with configuration importer and all went well after that.
Only thing was that for the NTP time server I had to change the hwclock to HPET (was TSC-low) in tunables. I don't think these are in the configuration file, but please correct me if I am wrong.
I didn't investigate further :-[
-
Thanks for the feedback, I was taking into account that primary only people with problems post. However it is a bit scary when you see a 5 page thread of people who's WAN are half the speed after upgrade. Unfortunately I live in an area where speed are not that great to start with so I really can't afford to lose half my speed. :)
But again thanks to everyone who responded, I really appreciate it.
-
Like the OP, I was holding back from upgrading as well, due to what seemed like a higher than normal quantity of upgrade-related issues with 20.7. Did a backup and went ahead and upgraded from 20.1.x to 20.7 and then 20.7.2, all "in-place" upgrades using the built-in script from current version. No issues thus far. Wireguard works as well, which is what I was most concerned about breaking.
-
I think IPv6 is essential and to few people are using/testing IPv6.
My impression of the OPNsense v6 support is it's implemented by someone proficient with v4 but never studied the actual RFCs. Shoving the configuration of multiple addresses and prefixes for an individual interface into the 'Virtual IP' paradigm is the biggest example of this, but the lack of explicit ULA handling and lazy DHCP firewall rules compound this impression.
I'd like to help correcting this, but I have no idea where to start beyond posting in this forum. IMO, refactoring the entire interpretation of v6 in OPNsense should be a dedicated project itself.
-
My impression of the OPNsense v6 support is it's implemented by someone proficient with v4 but never studied the actual RFCs. Shoving the configuration of multiple addresses and prefixes for an individual interface into the 'Virtual IP' paradigm is the biggest example of this, but the lack of explicit ULA handling and lazy DHCP firewall rules compound this impression.
This seems to be rather uninformed and overgeneralised. We did not implement the architecture for 'Virtual IP' in the first place, it has nothing to do with IPv6 in particular although people try to coerce ULA into their builds with it, and we did a lot of work in IPv6 over the years that is not found in other projects (see our dhcp6c and the latest multi-WAN support).
Most issues with IPv6 revolve around shifting prefixes and PPPoE parent IPv4 connectivity / reconnect hiccups.
Also, there is a kernel bug in radvd in 20.7 (FreeBSD 12.1) that seems to make multicast stuck after a while.
The rest is solved/broken by ISPs, modem, MAC address issues, settings mismatches etc.
Cheers,
Franco
-
My impression of the OPNsense v6 support is it's implemented by someone proficient with v4 but never studied the actual RFCs. Shoving the configuration of multiple addresses and prefixes for an individual interface into the 'Virtual IP' paradigm is the biggest example of this, but the lack of explicit ULA handling and lazy DHCP firewall rules compound this impression.
This seems to be rather uninformed and overgeneralised. We did not implement the architecture for 'Virtual IP' in the first place, it has nothing to do with IPv6 in particular although people try to coerce ULA into their builds with it, and we did a lot of work in IPv6 over the years that is not found in other projects (see our dhcp6c and the latest multi-WAN support).
Most issues with IPv6 revolve around shifting prefixes and PPPoE parent IPv4 connectivity / reconnect hiccups.
Also, there is a kernel bug in radvd in 20.7 (FreeBSD 12.1) that seems to make multicast stuck after a while.
The rest is solved/broken by ISPs, modem, MAC address issues, settings mismatches etc.
This is a much broader subject which likely needs to be captured in its own thread to be productive, but to address the above:
My post was absolutely uninformed and overgeneralised, in so much as it's born from my attempt to comprehend the design and configuration structure as an end user who has a moderate understanding of what v4 and v6 are capable of. The criticisms are not wholly unique to OPNsense, there's a persistent, broad impression v6 should just be treated like v4 with longer addresses, and this bleeds into design decisions which map v4 conventions to function with v6, leads to backporting and legitimising unnecessary hacks (NAT), and manifests as disproportionate friction when implementing core features v6 provides (multiple discreet address/prefix per interface). ULA configuration should be a core feature of any device claiming to function as a v6 firewall.
It was likely the right choice when first trying to make sense of everything, particularly when many of the RFCs and their revisions created more confusion than they resolved, but it's very much a technical debt which needs to be called out today. I'm very much interested in helping to correct this, but I have very limited capacity to do so beyond an assistance role.