Policy Routing Broken in 17.1?

[Carl E. Thompson]

Hello,

     I upgraded from 16.7 to 17.1. After upgrading, all of my firewall rules that forced traffic out through a particular gateway stopped working pretty much breaking my entire setup. I have multiple gateways some of which are over OpenVPN links. Different servers on my LAN need to be routed out through different gateways (different path to internet and different outbound NAT). I tried fiddling with it and creating floating rules instead of LAN rules to force the gateway but nothing worked. I ended reinstalling with 16.7 and restoring a config backup.

<rant>
     I love OPNsense and plan to continue to use it for my personal home network described here and in the future switch the work networks I manage from Sophos UTM to OPNsense. But are updates regression tested? In other words how much can I trust that an update will not break my networks? It seems to me that testing that core functionality like policy routing still works is something that could be done by adding a test case that is automatically run for each build. I see from perusing the forum there are other examples of rules that worked before but no longer working on 17.1. I would suggest that certain types of software projects (even open source) cannot afford to have breakage after upgrade because stability and reputation are things that are of paramount importance to the project's success. No one is going to trust their data (or their careers) to OPNsense if it gets a reputation of only working sometimes. To that end I volunteer to help set up a test harness on your test servers if you need people. Thanks!
</rant>

[franco]

Hi Carl,

We're feeling with you. In fact, we have been working on the issue and have a test kernel we would like you to try. Can you PM me if you are interested / if this is possible for you?

Updates are tested, of course. We've come a long way from the early days, mostly because users are quick and precise with their observations and some run the Beta, RC and Development versions. We are, however, largely at the mercy of using (a) whatever FreeBSD considers state of the art, (b) the amount of testing that users are willing to do before the releases are out and (c) not trying to stand still, which is very difficult with OS and third party libraries moving fast. I will not go into more detail. I for one am thankful for all of the reports that have helped to polish new features before they were releases. I'm grateful for everyone saying our release doesn't work, please improve them. It's something we cannot buy, only cherish.

The first major release before the stable update will always be problematic, even after months of testing. We've tried to make it very clear that 17.1 is an immense departure from our roots, also ending the FreeBSD 10 cycle. We've made the update work from the console only. Incidentally, we have thoroughly tested major upgrade code. We've written the "opnsense-patch" tool to deliver fixes before new releases are even out. We now have a new tool called "opnsense-revert" which will help users to spot problems in third-party packages in the future. We do what we can to make the transition and updates as simple as can be.

But I will not lie: there will always be issues that we cannot avoid / we will not foresee.

This is open source, open development, open participation. We live by it, (perhaps) we shall die by it.

What we can offer is swift execution in the form of 17.1.1 given that testing and troubleshooting communication works and eventually new images so that others will not have the same problems that you had. Does this fit your needs?


Thanks,
Franco