Turris Omnia Router Review

FYI: Try Turris Omnia, the open source router by Seth Kenlon of Red Hat. January 31, 2022.

NOTE: In early September 2020, Turris released a new product, the Turris Shield. It is a firewall, not a router. A brief summary is on the Secure Routers page.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

In June 2018, I was lent a Turris Omnia to kick the tires on.

The Turris Omnia may have been the first router sold for its security features. It is fully open source, both the hardware and software. The OS is called TurrisOS and it is based on OpenWRT. The Omnia is made by CZ.NIC, a non-profit organization in the Czech Republic. All their networking devices (Omnia, Mox and Shield) are made in the EU. The Omnia may have been the first router that self-updated its firmware. As of June 2021, it is available in the US from Amazon.com for $334.

Random Observations

The reason for my being interested in the Omnia is that the software is open source and security was a selling point. Also, it does not require you to join anything. Too many routers, such as Eero and Google Wifi, require you to establish an account with the router vendor. In these cases, we can never be sure what data the router is sending back to the vendor. The same is true for routers that offer anti-virus/security software as an add-on feature.

The target audience of the Omnia is very similar to that of the Pepwave Surf SOHO, techies. That said, the user interface of the Surf SOHO is much easier to use. The Turris is clearly oriented towards Linux techies. For example, Turris documentation assumes you know what a pigtail and a diplexer are. One of the first things I wanted to do on the Omnia was to enable Remote Administration. I looked everywhere but could not even figure how whether Remote Administration was enabled or not. Apparently it is always enabled and you control it using the firewall to block ports.

Comparing the Omnia with the Surf SOHO

Compare and contrast the two routers on big things:

The Surf SOHO is cheaper, roughly $200 vs. $350.
The Omnia can handle much faster ISP connections. The Surf SOHO maxes out at about 120Mbps, the Omnia is said to be full gigabit Ethernet. I don't have access to that fast an Internet connection but I have tested the Omnia on an ISP connection that was supposed to be 200Mbps and it tested at 230Mbps.
The higher end hardware in the Omnia lets it do many functions besides normal routing. The Surf SOHO is just a router.
The Omnia only has one copy of its firmware, the Surf SOHO has a backup copy of the firmware that you can boot into.
Both can set outbound firewall rules, something consumer routers do not support
The Omnia can handle two concurrent Ethernet connections to the Internet (WAN), the Surf SOHO only allows one Internet/WAN connection at a time. All other Peplink routers support multiple concurrent WAN connections, the Surf SOHO is their lowest end model. However, the Surf SOHO offers two other ways to connect to the Internet and these can be used as fallback, if the main connection fails. It can use a 4G/LTE modem plugged into its USB port or a Wi-Fi network (think hotel) as its Internet connection, which the Omnia can not.
The Omnia has an SFP port for use with an optical network. The Surf SOHO does not.
The Omnia can self-update, the Surf SOHO can not. When it is auto-updating, there is no button to check for updates now, you are at the mercy of a hidden schedule. Does it check daily? weekly? hourly? You can set a preferred time for the router to reboot itself. Automatic updating supports an option, just like Windows, to check for updates but not install them until they are manually approved. However, when you give approval, there is no status of the update. Pretty much every other router tells you that the update is downloading and then that its installing, along with a progress bar. With the Omnia, you have to know to check for notifications. A notification is only issued after the update is done. There is also an option to auto-install updates with a delay (you chose the number of hours to wait). I am not sure what purpose this serves. If you don't want auto-updating, it can be disabled, but when it is disabled, there is no check for update button. Beats me how you get updates in this case.
Peplink offers access to the latest firmware and release notes on their support page. However, they only provide access to the latest version and they do not offer a firmware history. Turris maintains a firmware change log with a release history, so you can verify that automatic updating is really working. However, as of October 1, 2018 the change log was no longer being updated. It was missing the last two updates. Peplink offers much more extensive descriptions of the changes made in each firmware update.
The Omnia supports software called Netmetr (available in the simple web interface) that measures your upload and download speed. The Surf SOHO does not have a feature that measures speed. In my tests, on an ISP connection of 100Mpbs, NetMetr reported download speeds of 48 and 55Mbps. I have gotten faster speeds with WiFi N on the 2.4Ghz band. Upload speeds were accurate. I connected a very old PC to the Omnia via Ethernet and it speed tested at 94Mbps and 98Mbps. Clearly the Omnia is not the problem, Netmetr is. Also, the speed test results are not kept in the router, when you want detailed results, you are taken to the netmetrz.cz website. And, to be clear, the Surf SOHO does measure speeds of all attached devices both individually and in aggregate, it just does not have a built-in ISP testing feature.
The Omnia has two web based user interfaces, a simple one and an advanced one. Each has a name (Foris and Luci) and each gets its own password and URL. The Surf SOHO has only one user interface and you are never concerned with the URL. The simple Foris interface has no status page with an overview of the router status.
Both routers support a command line SSH interface. With Peplink, it is disabled by default, with the Omnia it is enabled by default. Quoting from this Turris page Accessing the terminal: "The SSH daemon will start on the standard port number 22 after setting the root password in Foris web interface." This is vague. SSH is not open on the WAN side.
The Omnia user interface tells you that passwords must be between 6 and 128 characters. Peplink does not document their password rules.
Both support VLANs which allow you segment the network. With the Surf SOHO, you can follow my instructions which explain the concepts of network segmentation and walk you through configuring it with the Peplink user interface. I think it is fair to say that implementing VLANs with the Omnia is much harder. You are involved with the internal hardware of the router (which Peplink shields you from) and a text based configuration. See Configuring internal VLANs - Omnia.
You can plug a USB storage device into the Omnia and use the router to share files. The USB port on the Surf SOHO is only used for 4G/LTE antennas that provide Internet access.
The Omnia can function as as a NAS (Network Attached Storage) and as a DNLA (Digital Living Network Alliance) server. The Surf SOHO can not.
With the Omnia you have enable/disable Wi-Fi 1 and Wi-Fi 2 which adds confusion. With the Surf SOHO you deal with the 2.4GHz and 5GHz bands directly. This stems fromt he fact that the Omnia has two Wi-Fi radios, one does both frequency bands, the other just does one band. This is not a thing with the Surf SOHO. Both Wi-Fi 1 and 2 have an option for enabling a Guest Wifi network. It is not clear if they refer to the same Guest network or if it supports two different Guest networks. The Surf SOHO supports 16 SSIDs and each of them can be configured as a Guest network, or not, up to you. The configuration options for the Guest Network on the Omnia are in the LAN section of the user interface which makes no sense.
Both can send you an email message about certain things you want to be alerted to. Peplink requires you to configure the email server details on your own, Turris does this too but also offers a service for sending emails.
The Omnia can be a print server, the Surf SOHO can not. I didn't look into this feature.
Both routers deserve praise for the way they handle problems. The Surf SOHO can generate a diagnostic report that you can send to Peplink to debug a problem. You will see this in the Status Tab -> Diagnostic Report. There is a link to download the report. Turris has documentation on how to report a problem, and their operating system can also generate diagnostics. See a screen shot.

Compare and contrast the two routers on small things:

The Omnia supports two different User Interfaces, a simple one called Foris and an advanced one called LuCI. The Surf SOHO has just one interface, but sections of it have advanced options that are not enabled or displayed by default. For example, by default, the Surf SOHO does not enable or display anything about VLANs.
To logon to the Omnia, you only need a password. The Surf SOHO requires both a userid and a password. Plus, the Surf SOHO lets you change the userid, you are not locked into "admin"
The Surf SOHO supports two userids, one is an administrator the other is a read-only user. The Omnia supports three different passwords, for Foris, LuCI, and SSH. The three passwords can be the same or different.
Both routers can save the current configuration to a file. Turris points out that their backup does not contain any passwords. Not sure about Peplink backups. However, Turris warns that there are some cases where configuration changes are not contained in the Omnia backup. Peplink has no such warning.
Both routers can send you an email when certain bad things happen. The Turris has an advantage, in that they provide their own (optional) email sending service, Peplink does not.
The Omnia has two USB ports, the Surf SOHO only one
Both are ugly

Comparing lights:

Surf SOHO: There are two small and dim lights in the front. One is a Wi-Fi status indicator, the other shows the status of the router itself. The back has two fairly bright LEDs on each Ethernet port (orange and green). These lights are great to have, they indicate the speed of the Ethernet port, whether data is being transmitted and, in the worst cases, that at least the link is alive. For example, these lights are the best way to detect a bad Ethernet cable. In a dark room some people may find them a bit too bright and there is no way to dim or disable the Ethernet LED lights. Here is a detailed image of the front and back from Peplink.
Turris Omnia: The Ethernet ports are in the back and they do not have indicator LEDs. This seems like a corner that should not have been cut in a high end device. All the lights are in the front and I found them confusing. For example, the PCI1 LED is the status of the 5GHz Wi-Fi network and the PCI2 light is for 2.4GHz. Clearly you will need a cheat sheet to interpret the lights. With no clients attached to the router but it being on-line, the PCI3 light was solid blue at some point but later it wsa off. What does that mean? Don't know. The User Manual says this light is unassigned. You might want to put your own labels on the front, but even then, the lights are blue so the standard green is good and red is bad does not apply. The globe LED indicates that the router is online, but even with no clients connected, it blinks very quickly and is annoying. On the upside, there is a button on the front that you can push to dim the lights. There are maybe a half dozen or so different brightness settings, including completely off.

Turris, like many other routers, can collect data about network activity, something that Peplink does not do. Turris collects data to research attacks. Data collection is optional and off by default. It is also disabled if automatic updating is disabled. Quoting their description:

"If you own the Turris Omnia router, you can join the research project called Project:Turris and ... contribute your data. In return you can check the statistics about your connection and attacks to your router. We will also contact you if ... our analyses reveals a potential threat in your network ... If the data collection is enabled ... either disable the emulated services (so-called minipots, which emulate services that are a common target of internet attackers) or you can choose whether you opt-in for the collection of credentials entered by the attackers."

Ports Closed (not stealth) by default

Pretty much the first thing I did the first time the Omnia was online was to run Steve Gibsons Shields Up! test of assorted router ports. The Omnia failed. By this I mean that most ports were CLOSED rather than STEALTHed. See the results for the lower numbered ports and the higher numbered ports. A stealthed port is the most secure state and that is what all Peplink ports are. A closed port is far better than an OPEN port, but it does mean that the router responded to a request on that port.

Next, I tested the same thing but in a different way. With the WAN port of the Omnia connected to a LAN port of another router, I used nmap to scan the Omnia's WAN port. It did not go well. I ran the command below using version 7.70 of nmap
nmap -p- 192.168.1.180
It reported that "All 65535 scanned ports on 192.168.1.180 are closed." Since ShieldsUp! had reported a few stealthed ports, I ran nmap on a public Peplink router and it did show filtered ports, which is the nmap equivalent of stealth. And, for good luck, I re-ran the test on the Omnia using just a few ports. That too, said the ports were closed, not stealth/filtered (see report).

To rule out any effect from the massive port scanning, I powered the router off, powered it back on and tested just a couple ports using
nmap -p 99 192.168.1.180
where 99 was the port number. I tested all the ports that ShieldsUp! said were Stealth and nmap said they were closed, not stealth/filtered. After enabling Remote Administration with HTTPS, nmap correctly detected port 443 was open. Nmap is fine, these ports are really closed.

I should have checked the Turris Omnia forum first thing. This has already been addressed here Closed ports instead of stealth ports. Apparently the default action in OpenWRT is Reject which responds with a RST packet. To stealth the port, you have to change WAN input to Drop in the firewall section.

The advice lacked specifics, so my best guess was: Luci -> Network ->Firewall -> Zones -> Wan->reject zone, where I changed the Input field from Reject to Drop. That worked, nmap now shows the ports as filtered. Maybe this needs to also be done for the Guest_turris -> wan zone. Beats me.

Using the Turris Omnia

The Peplink router is easier to use than the Omnia.

From the simple web interface (Foris) you can click a link and go to the advanced one (Omnia). However, from the advanced interface there is no link to the simple one. Switching requires changing the URL in your web browser.

The advanced Omnia UI (Luci) is for Linux techies with a networking background. I might have included myself in that category, but no, I was mostly lost here. Not only is there no help or explanation of anything in Luci, there is not even a link to a page of documentation. A couple examples: The WAN interface has checkboxes for Masquerading and MSS clamping. The firewall section supports zones, a concept that was new to me, so of course I am clueless about inter-zone forwarding. Port Forwarding I know, but inter zone? You just have to know what these (and many other) things are. If you don't, then the Omnia is not a good fit for you.

Turris documents how to disable Wi-Fi at night here WiFi off during night. This is much easier with Peplink, which offers a GUI interface. The Omnia uses a CRON script, the same approach Linux and Unix nerds were using 25 years ago.

I could not figure out how to enable remote web administration using only HTTPS but on a non-standard port. So, I asked the forum. Someone suggested using SSH on a non-standard port instead or using OpenVPN. With Peplink this was trivially easy, I am not sure it is possible with the Omnia. Maybe I could forward the non-standard port to 443 even though 443 itself is closed? The bigger point is that the Omnia is only for network experts, people who know the answer to this question already. Turris has no documentation, that I could find, about securely configuring the router.

In Luci, at System -> software you get a long list of the installed software and the version number for each module. That's fine, as long as you know what socat, tc, usign, udev, uci, vim-full and xfs-growfs are. If you don't know, the list is almost useless.

I also wondered if the Omnia can monitor connections made by one device? This is a great Peplink feature as it lets me audit a device on the LAN. On the Forum, someone suggested a parental control feature called pakon which I installed and tried out. It does not do this type of logging, the logging that let me create the Phoning Home section above. There may well be software that can run on the Omnia to do all sorts of logging and auditing, but I am on my own to figure it out.

The advanced Luci web interface does not offer LAN side restrictions for access to the router itself. It does not seem to be able to limit access to HTTPS or limit access by IP address or limit access at all. Perhaps a firewall rule or two can serve this function? The Pepwave Surf SOHO makes it trivially easy to force all LAN side access to use HTTPS and do so on a non-standard port. The Surf SOHO does not limit access by IP address, but if you are using VLANs, you can limit router access to just one VLAN.

NMAP: A scan from the LAN side of the Omnia found these open TCP ports: 22 (SSH), 53 (DNS, totally expected and required), 80 (HTTP) and 443 (HTTPS).

When I remotely logged in to the Omnia, I was a ghost. That is, my connection to the router did not show up as a DHCP lease or an associated station. I am not sure if someone locally connected to the Omnia can tell that there is a remote user connected to it.

The Omnia will log you out of the simple web interface after a period of inactivity. However, what the time period is, is not shown and you can not change it. With Peplink routers you do get to set the timeout period.

After trying Pakon briefly, I was not impressed with it, so I tried to un-install it. This resulted in an error
The server closed the connection without sending any data.
http://192.168.11.11/cgi-bin/luci/admin/system/packages
The third time I re-displayed this page, it worked.

But then, more confusion. There is also a pakon-lists module. Do I remove that as part of removing Pakon? Beats me. I did, and got another error:
Removing package pakon-lists from root...
WARNING: You probably just removed a package that was installed as part of a user list or the basic system.
This package will return during the next updater run. We suggest you disable the user list instead.
I am clueless about what is going on.

I also wanted to remove netmetr but decided against it because not only is there a netmetr module, there are three other modules: foris-controller-netmetr-module, foris-netmetr-plugin 2.3-1 and foris-netmetr-plugin-l10n-cs. Should these also be removed? Beats me. Luci is not Linux for Dummies.

See a demo of Foris the simple user interface.

Wi-Fi

Wi-Fi starts out confusing. To begin with, you are forced to deal with Wi-Fi 1 and 2 (Foris -> Wi-Fi), one of which is multi-band (1) the other only does 2.4GHz (2). Then, if you want a Guest network (I did not bother) you have to figure out the difference between Foris -> LAN (yes, LAN, that is not a typo) -> Enable Guest network and Foris -> WiFi -> Enable Guest WiFi. Good luck with that.

When I enabled a Wi-Fi network from an Ethernet connected computer, the first result was this error
A connection was reset (corresponding to a TCP RST).
https://192.168.11.11/foris/config/main/wifi/
Despite this, the network was created.

I connected a tablet running Android 7 and it worked fine. A speed test with the Speedtest.net app, produced an expected result.

I connected a phone running Android 9 and it could not get to the Internet at all. There was no need for me to test this (though I did, of course), the Operating System put up its own warnings. The phone was perfectly connected to the network, it had a LAN side IP address and the Omnia was set as the DNS server. A LAN scan with the Fing app, ran fine, it saw the Omnia and an Ethernet connected computer and the Android 9 phone. The only thing that did not work, was getting to the Internet. Beats me why. This was not a one-time fluke. The next day, after cold booting the Omnia, the same thing happened. Again, Android 7 devices worked fine.

A Chromebook in Guest mode connected to the Wi-Fi for a minute, then nothing. I saw a couple websites and then went to Speedtest.net. The download test seemed to hang, it never got to the upload test. There were no notifications in Foris about any problems.

I logged out of Guest mode and logged back in to the Chromebook as a Google user. As before, it worked fine initially but the Speedtest.net test hung before the upload test. This time, however, the problem seemed to be just speedtest.net, the Internet connection remained active. So, went to Fast.com to run a speed test and that proved fatal. After hanging for a bit, the website said "Could not reach out servers to perform the test. You may not be connected to the Internet". Sure enough, the Internet connection no longer worked. The Chromebook was still connected to the Omnia's Wi-Fi network.

The speedtest.net website worked just fine from an Ethernet connected computer. It reported an expected speed and did not break anything.

The Foris interface says that Guest Wi-Fi users are blocked from directly accessing the router. Great. I did not verify this. It also says that Guest users "are allowed to access the internet, but aren't allowed to access other devices.." It's not clear from this if Guest users can see each other. The Guest network defaults to a different subnet than the main LAN which is good.

Phoning Home

No one who buys a router claiming to be secure, wants it phoning home to the hardware manufacturer. Both Turris and Peplink let you use their routers without having an account with them, which is great. I tested the Surf SOHO and confirmed that it does not phone home to Peplink. However, even with automatic updating disabled, the Omnia does phone home.

Below is an edited log file showing the outgoing connections initiated by the router for the router. That is, there were no devices attached to the Omnia. The log is from a Pepwave Surf SOHO router. The WAN port of the Omnia was connected to a LAN port of the Surf SOHO. Omitted from the log are requests for the current time of day using NTP. These are all UDP requests to port 123. Both the Omnia and the Surf SOHO make a lot of these requests.

The first two columns are the date and time. DST is the destination IP address. PROTO is the protocol, either TCP, UDP or ICMP. SPT is the source port. DPT is the destination port.

The first two entries are Pings (ICMP type 8) and they were issued shortly after the router was powered on. Then, it went almost a half hour without making any outgoing connections. Then on the hour at 3PM and again on the hour at 4PM, it made a flurry of connections. It seems like there is a schedule. The Omnia made secure HTTPS connections on port 443 to two different computers in the Czech Republic: 217.31.192.101 (api.turris.cz) and 217.31.192.69 (repo.turris.cz).

 Oct 01 16:01:05 DST=217.31.192.101 LEN=60 ID=63372 PROTO=TCP SPT=60710 DPT=443 

Oct 01 16:00:32 DST=217.31.192.101 LEN=60 ID=63371 PROTO=TCP SPT=60710 DPT=443
   
Oct 01 16:00:16 DST=217.31.192.101 LEN=60 ID=63370 PROTO=TCP SPT=60710 DPT=443 
  
Oct 01 16:00:08 DST=217.31.192.101 LEN=60 ID=63369 PROTO=TCP SPT=60710 DPT=443 
 
Oct 01 16:00:04 DST=217.31.192.101 LEN=60 ID=63368 PROTO=TCP SPT=60710 DPT=443 
 
Oct 01 16:00:02 DST=217.31.192.101 LEN=60 ID=63367 PROTO=TCP SPT=60710 DPT=443 
 
Oct 01 16:00:01 DST=217.31.192.101 LEN=60 ID=63366 PROTO=TCP SPT=60710 DPT=443  

Oct 01 16:00:01 DST=217.31.192.69   LEN=60 ID=34552 PROTO=TCP SPT=56822 DPT=443   

Oct 01 15:00:32 DST=217.31.192.101 LEN=60 ID=49757 PROTO=TCP SPT=60702 DPT=443  

Oct 01 15:00:16 DST=217.31.192.101 LEN=60 ID=49756 PROTO=TCP SPT=60702 DPT=443  

Oct 01 15:00:08 DST=217.31.192.101 LEN=60 ID=49755 PROTO=TCP SPT=60702 DPT=443  

Oct 01 15:00:04 DST=217.31.192.101 LEN=60 ID=41884 PROTO=TCP SPT=60704 DPT=443  

Oct 01 15:00:04 DST=217.31.192.101 LEN=60 ID=49754 PROTO=TCP SPT=60702 DPT=443  

Oct 01 15:00:02 DST=217.31.192.101 LEN=60 ID=41883 PROTO=TCP SPT=60704 DPT=443  

Oct 01 15:00:02 DST=217.31.192.101 LEN=60 ID=49753 PROTO=TCP SPT=60702 DPT=443  

Oct 01 15:00:01 DST=217.31.192.69   LEN=60 ID=4622   PROTO=TCP SPT=56820 DPT=443   

Oct 01 15:00:01 DST=217.31.192.101 LEN=60 ID=41882 PROTO=TCP SPT=60704 DPT=443  

Oct 01 15:00:01 DST=217.31.192.101 LEN=60 ID=49752 PROTO=TCP SPT=60702 DPT=443  

Oct 01 14:32:13 DST=217.31.192.101 LEN=84 ID=239    PROTO=ICMP TYPE=8 CODE=0 ID=20491 SEQ=0
 
Oct 01 14:32:08 DST=217.31.192.101 LEN=84 ID=21    PROTO=ICMP TYPE=8 CODE=0 ID=18187 SEQ=0

Outbound connections made by the Turris Omnia

I asked about this in the forum. One person guessed that it might be configuration backups, data collection or netmetr. I don't know what any of these things are. Someone from Turris said that it is an indented behavior and that there are several tasks that might cause this. The whole idea of using a router that does not require you to have an account with the hardware vendor is to avoid the router phoning home, so this is disappointing. He suggested it might be a certificate revocation check or one of several similar things, "containing no or minimal details about the router."

The Turris person pointed out a big difference between them and Peplink (and everyone else for that matter), all the software from Turris is open source, so you can read the source code. This does me no good as I don't know where the code is, I can't read the C programming language and I don't know what software to look for. He also pointed out that since I have root access, I can disable most/all things. Startup scripts are in /etc/init.d/ and scheduled scripts are in /etc/cron.d/. This too does me no practical good. I poked around the advanced web interface and did not see a file manager app, so even if I understood the scripting language, it seems i have to SSH into the router to see the scripts.

To try and figure out what data was being transmitted every hour on the hour, I looked at the system log. As you can see below, it has something to do with stats and a registration for contract status.

00:01 info /usr/sbin/cron[4795]: (root) CMD (nethist_stats.lua)

00:01 info /usr/sbin/cron[4797]: (root) CMD (/usr/bin/get-api-crl)

00:01 info /usr/sbin/cron[4791]: (root) CMD (/usr/bin/rainbow_button_sync.sh)

00:01 info /usr/sbin/cron[4798]: (root) CMD (   /usr/bin/notifier)

00:01 info /usr/sbin/cron[4799]: (root) CMD (/usr/share/server-uplink/registration_code.sh)

00:01 info /usr/sbin/cron[4800]: (root) CMD (/usr/share/server-uplink/contract_valid.sh)

00:02 err server_uplink[]: Failed to download contract status

00:01 info /usr/sbin/cron[17780]: (root) CMD (nethist_stats.lua)

00:01 info /usr/sbin/cron[17783]: (root) CMD (/usr/bin/updater-supervisor -d --rand-sleep)

00:01 info /usr/sbin/cron[17776]: (root) CMD (/usr/bin/rainbow_button_sync.sh)

00:01 info /usr/sbin/cron[17785]: (root) CMD (/usr/share/server-uplink/contract_valid.sh)

00:01 info /usr/sbin/cron[17782]: (root) CMD (/usr/bin/get-api-crl)

00:01 info /usr/sbin/cron[17786]: (root) CMD (/usr/share/server-uplink/registration_code.sh)

00:01 info /usr/sbin/cron[17784]: (root) CMD (   /usr/bin/notifier)

00:02 err server_uplink[]: Failed to download contract status

00:36 err server_uplink[]: Failed to get registration code

00:01 info /usr/sbin/cron[20989]: (root) CMD (nethist_stats.lua)

00:01 info /usr/sbin/cron[20990]: (root) CMD (/usr/share/server-uplink/registration_code.sh)

00:01 info /usr/sbin/cron[20985]: (root) CMD (/usr/bin/rainbow_button_sync.sh)

00:01 info /usr/sbin/cron[20992]: (root) CMD (/usr/share/server-uplink/contract_valid.sh)

00:01 info /usr/sbin/cron[20991]: (root) CMD (/usr/bin/get-api-crl)

00:01 info /usr/sbin/cron[20993]: (root) CMD (   /usr/bin/notifier)

00:01 err server_uplink[]: Failed to download contract status

00:34 err server_uplink[]: Failed to get registration code

System log for the top of the hour

This additional information was recognized by someone from Turris who responded on their forum: "This is remnant of project Turris history. Originally it was research project and routers were given away for free under a contract. This script you see is checking if given router is under contract. The usecase is to automatically register router for data collection. I can look into it if we are able to drop it on Omnia. But in general we are working on new data collection system that is going to be more open and less dependent on exact settings on router. With introduction of new data collection system all these remnants are going to be dropped."

Mystery partially solved. I say partially because someone else noticed their Omnia phoning home too: Why does the router access project.turris.cz when I’m opted out of data collection? (Oct. 7, 2018). Parts of that forum posting are over my head, but it does not seem like it has a full conclusion. In addition, the forum user also complained that HTTPS requests to api.turris.cz were insecure because it used a self-signed certificate.

DNS

DNS is a bit of a struggle on the Omnia. The router uses the Knot resolver (a.k.a. kresd) as its DNS server which is not standard for OpenWRT. As a result, the documentation warns that "changes made in the DNS settings in LuCI won't manifest," which I assume means will be ignored. Providing a user interface that does not do what it says its doing is not good.

They chose Knot because it supports DNSSEC which, for the few domains that are signed electronically, prevents spoofing of in-flight DNS requests. It does not, however, prevent the hijacking of DNS servers.

The documentation says that without DNSSEC, the router and the Turris switchboard will not communicate. What the Turris switchboard is, is not explained.

Also not explained is how to configure the LAN to use my preferred DNS servers. Some people like OpenDNS, others like Quad9 or Cloudflare. Being able to use alternate DNS servers is, to me, a big feature so not explaining how to do this is a big omission. With Peplink, it is simple to configure your preferred DNS servers both for a WAN connection and for each VLAN.

Peplink can also insure that its DNS servers are always used, even when an attached device is configured to use different servers. This too, is not addressed by the Omnia in its DNS documentation.

Both the Omnia and the Surf SOHO offer a choice: they can serve as your DNS servers or they can defer to your ISP DNS servers. With Peplink this is controlled by a DNS Proxy checkbox.

The Omnia refers to this as DNS forwarding. Forwarding on means use the ISP DNS servers, forwarding off means use the Omnia as the DNS server. Whether forwarding was disabled or not, the clients see the router as their one and only DNS server. Forwarding with DNSSEC enabled broke my network. Forwarding with DNSSEC disabled work fine for me. When you disable forwarding, there is no option to specify your desired DNS servers.

Finally, Peplink has some DNS tricks that the Omnia does not seem to offer. A feature called Local DNS Records lets me configure the DNS server in the Surf SOHO to block some domain names. For example, I can set facebook.com to 127.0.0.1 and never see the facebook website (except when using a VPN or Tor). The Omnia documentation says nothing about this. Peplink also supports more generic blacklisting, letting me, for example, block all .cm domains. Can Omnia do this? Beats me.

Buying the Omnia

June 18, 2021: The Omnia is for sale in the US at Amazon for $334.

Availability History

Shipments were initially expected to start in April 2016, then in Oct. 2016, then in Dec. 2016. By May 2017 it was for sale in roughly 25 countries, including Germany, Ireland, Greece, Austria, Switzerland, Spain, Belgium, Denmark, France, Finland, Italy, Poland, and England. As of June 2018, it was available all over Europe, but not in the U.S.

Like Eddie Murphy in the 1988 movie, the Omnia router is Coming to America. In June 2017, the company said they were working on FCC certification for the U.S. They guessed, at the time, that it would go on sale in the U.S. in the Fall of 2017. As of June 2018, FCC approval is expected in October 2018. Union Technology Cooperative of Middleton, WI plans on selling it in the US, after FCC approval. They plan to localize it for the US, test it and ship it with the latest software. They expect to sell it for $349 (not sure if thats with 1GB or 2GB of ram).

Vendor Documentation

One clump of documentation is at doc.turris.cz/doc/en/start

Another clump of documentation is at doc.turris.cz/doc/en/howto/start

Video Tutorials are at doc.turris.cz/doc/en/howto/video

Links to all the manuals are at: doc.turris.cz/doc/en/howto/omnia_manuals

First thing: doc.turris.cz/doc/_media/en/howto/omnia_manual_en.pdf. Four pages of initial hardware setup, an overview of the lights, ports and connectors and instructions for a factory reset.

Initial setup and Foris: doc.turris.cz/doc/en/howto/foris. Foris is the name of the simple web based user interface. There is a second interface with advanced features called LuCI.

Troubleshooting: doc.turris.cz/doc/en/troubleshooting/start

There are three different generations of the Omnia router. See what they look like at doc.turris.cz/doc/en/howto/turris_versions and read more about them here docs.turris.cz/hw/omnia/revisions. The last two versions (as of Nov 2020) are known as Omnia 2019 and Omnia 2020.

The Turris family of networking devices consists of the Omnia, the Mox and the Shield. All are made in the EU.

Forums: https://forum.turris.cz

CZ.NIC on Github

Turris offers to answer questions emailed to info at turris.cz

OpenWRT Documentation

OpenWRT project documentation

The UCI system UCI stands for Unified Configuration Interface and it is used to configure OpenWrt services. On the Omnia, it is not unified, as the router also has a Foris interface.

Reading List

I have found very few reviews of the Omnia router. If you know of any not shown here, please let me know by email (see bottom of the page).

Review: Turris Omnia (with Fiber7) by Michael Stapelberg March 25, 2017.
December 2015: Open source router makes all other routers look woefully behind the times By Jack Wallen at Tech Republic. It does not look at all like the picture in this article. At the time, it cost $190 with 1GB of ram.

In April 2018, cz.nic introduced a new Safe router but it was only available to Czech institutions.

For a while, the Omnia could also run the Next Generation Firewall, Untangle. The Home edition of Untangle costs $50/year to license. It runs on PCs, and their own appliances. It used to also run on the Omnia and the Linksys WRT1900ACS. However, the system resided on an external USB flash drive and they found these devices did not hold up to long term use. According to a September 2018 notice, the 14.0.1 builds of Untangle will continue to work.