Turris OS 7.1.0 is in RC now!

Community office Testing branches
, , , , ,
1

Dear Turris users,

We just release Turris OS 7.1 into RC. There are two big changes.

One is that we are migrating the default firewall to Firewall4 that is based on nftables and we are also migrating all the Turris Sentinel integration over. If you had some iptables based manual scripts, those will stop working now and would need to be migrated manually. Anything that you configured through LuCI should work same as before.

Other change is a big refresh of reForis user interface. Changes are mainly under the hood. Everything should be faster and better and newer, but there is also a new kick-ass feature. We have a dark mode now! So give it a try, come to the dark side :wink:

We tested the release extensively, but as those changes are big, please let us know if you encounter some issues.

18 Likes
3

Great news!

Does anyone know a good guide on migrating iptables scripts to nftables?

4

ipsets also need to be migrated?

1 Like
5

I updated my Turris 1.0 router and the DNS resolver mostly stopped working. It will resolve .cz domains but not .com or .org or whatever. I’m getting SERVFAIL with nslookup performed on the turris itself via ssh. Had to reconfigure the dhcp server to give me my connection provider’s DNS servers. Switching the resolver to forwarding also doesn’t help.

1 Like
6

7.0.3 → 7.1.0 RC1 update okay. No noticeable cable/wifi/internet interruption. Restart was needed.

Internet was working even after the update but before reboot.

Transmission is still hogging CPU.

Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards, UBoot 2022.10. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, Syncthing, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, Strongswan IKEv2 VPN, morce.

For Reforis to look nice, I had to delete browser caches (Ctrl+F5). Before I did that, Reforis looked like this:

obrazek
obrazek1473×948 100 KB

Another visual glitch (that’s not corrected by cache deleting) is in the darkmode:

Screenshot 2024-10-18 at 01-42-57 Interfaces - reForis Turris

vs

Screenshot 2024-10-18 at 01-43-06 Interfaces - reForis Turris

I.e. no indication of empty ports.

I had to do some adjustments for manually added iptables rules I had for PPtP VPN

I converted these:

iptables -A input_rule -i ppp1 -j ACCEPT
iptables -A forwarding_rule -i ppp1 -j ACCEPT
iptables -A forwarding_rule -o ppp1 -j ACCEPT
iptables -A output_rule -o ppp1 -j ACCEPT

to /etc/config/firewall:

config rule
        option direction 'in'
        option target 'ACCEPT'
        option device 'ppp1'
        option src '*'
        option name 'PPTP ppp1 in'
        list proto 'all'

config rule
        list proto 'all'
        option name 'PPTP ppp1 forward in'
        option target 'ACCEPT'
        option device 'ppp1'
        option dest '*'
        option src '*'
        option direction 'in'

config rule
        list proto 'all'
        option name 'PPTP ppp1 forward out'
        option target 'ACCEPT'
        option device 'ppp1'
        option dest '*'
        option src '*'
        option direction 'out'

config rule
        option direction 'out'
        option target 'ACCEPT'
        option device 'ppp1'
        option dest '*'
        option name 'PPTP ppp1 out'
        list proto 'all'

fail2ban package still brings in dependency on iptables. I’ve reported that upstream: fail2ban still depends in iptables · Issue #25163 · openwrt/packages · GitHub .

I also updated GitHub - peci1/fail2ban_openwrt: OpenWRT support for fail2ban to reflect the switch over to nftables, making PPtP jail working again (and I also use the default distributed OpenVPN jail). In the jails, I had to change not only banaction, but also protocol from all to tcp, udp - otherwise, fail2ban failed to start the jails due to nft syntax error.

6 Likes
7

Hi,

Turris Omnia 2020 HBT PPPoE Wan Configuration + Ad Block + New devices detection + Dynamic Firewall + Latest Firmware (U-Boot, MCU and FR Image).

All is O.K. Reboot needed. Nicer Reforis GUI.

Thanks!

8

I finally got back to looking into upgrades. After the problem with the 7.0 rc, I didn’t have time and just kept the updater disabled (Turris OS 7.0 is in rc! - #87 by miska). I followed the docs to upgrade the bootloader firmware that was mentioned in that thread, and then tried again today. It uptated to 7.1.0 w/o issues. I’m happy to report that said problem no longer exists, and I haven’t seen any visible regressions so far!

1 Like
9

After trying to debug the resolver, I realized there’s actually a problem with the firewall, as I apparently had no rules loaded at all. Used schnapps to roll back to 7.0.3.

10

Haven’t you used iptables -L to figure that out, right?

11

I tried dumping both iptables and nftables (hopefully correctly).

12

@julien113, can You write what steps are required to have working docker?
Or currently it works out of the box?

13

@Cabal, when I first did the migration to nftables (when the v7.1.0 was announced in the hbl branch) after multiple test, the most simple change to keep docker working was the following :

  • move to hbl
  • Upgrade all packages
  • Reinstall the 2 packages kmod-ipt-nat kmod-ipt-contrack
  • Reboot the router

Doing that, docker hasn’t stop working and since then I moved to hbk and now hbt branche without any issue, but I’m not sure if in the last updates those packages are still removed. I saw that few iptables dependancies seemed to be added afterward (according to few packages names) but not so sure about the kmod one.

1 Like
14

Thank You.
When I know the possibly-missing modules, I’m ready for update.
I run Homeassistant in Docker, and winter is coming:)

15

Well, it is a little bit trickier that you would expect. Once you switch to nftables, you would end up with iptables command that is just an interface to nftables. To inspect the real iptables, you need iptables-legacy. Or if your reboot the router, you should end up with full nftables. After migration, we don’t flush the iptables as you might need new kernel modules for nftables to work and you might be upgrading from older kernel and thus you wouldn’t have them. Therefore, we keep your firewall as it was and switch to nftables after reboot with new kernel that has all the modules.

Long story short, checking the state of your firewall directly after the switch before reboot is not easy. But resolver should work anyway. What resolver are you using?

16

I did the reboot right after update as the router requested it anyway. The resolver is unbound, AFAIK that’s the default on 1.0 still and there’s not a way to easily switch that in the GUI or am I missing it?

17

Also I have one related complaint about the snapshots, rolling back to a pre-update snapshot after the update was approved (I have approves enabled) means it will immediately update again, I assume it’s because the snapshot is taken after the approval so it’s already recorded on the filesystem. Had to rollback to the 7.0.3 post update snasphot to avoid this issue.

18

Dear Turris users,

We just release the second RC for Turris OS 7.1. This one includes fix for the 5g kit.

:bug: Bug Fixes

  • 5g-kit: Handle broken U-Boot environment
5 Likes
19

@muzikr my Omnia says:

Error notifications
===================
Updater execution failed:
INFO:Target Turris OS: 7.1.0
WARN:Request not satisfied to install package: knot-resolver
ERROR:
inconsistent: Requested package turris-netboot-tools that is not available.
20

Hello, I just noticed that with the switch to nftables, minipots are much more aggressive than they used to be before. Having HTTP miniport active on the main router prevents any tcp/80 traffic to any host behind the main router even if the firewall rule is there to allow it. The traffic does not even end up on the minipot, it is just blackholed.