|Router Security||Turris Omnia Router||
Website by |
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 its based on OpenWRT. It is from CZ.NIC, a non-profit organization in the Czech Republic. The Omnia may have been the first router that self-updated its firmware.
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.
Compare and contrast the two routers on big things:
Compare and contrast the two routers on small things:
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."
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.
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.
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 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).
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.
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: 18.104.22.168 (api.turris.cz) and 22.214.171.124 (repo.turris.cz).
Oct 01 16:01:05 DST=126.96.36.199 LEN=60 ID=63372 PROTO=TCP SPT=60710 DPT=443 |
Oct 01 16:00:32 DST=188.8.131.52 LEN=60 ID=63371 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:16 DST=184.108.40.206 LEN=60 ID=63370 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:08 DST=220.127.116.11 LEN=60 ID=63369 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:04 DST=18.104.22.168 LEN=60 ID=63368 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:02 DST=22.214.171.124 LEN=60 ID=63367 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:01 DST=126.96.36.199 LEN=60 ID=63366 PROTO=TCP SPT=60710 DPT=443
Oct 01 16:00:01 DST=188.8.131.52 LEN=60 ID=34552 PROTO=TCP SPT=56822 DPT=443
Oct 01 15:00:32 DST=184.108.40.206 LEN=60 ID=49757 PROTO=TCP SPT=60702 DPT=443
Oct 01 15:00:16 DST=220.127.116.11 LEN=60 ID=49756 PROTO=TCP SPT=60702 DPT=443
Oct 01 15:00:08 DST=18.104.22.168 LEN=60 ID=49755 PROTO=TCP SPT=60702 DPT=443
Oct 01 15:00:04 DST=22.214.171.124 LEN=60 ID=41884 PROTO=TCP SPT=60704 DPT=443
Oct 01 15:00:04 DST=126.96.36.199 LEN=60 ID=49754 PROTO=TCP SPT=60702 DPT=443
Oct 01 15:00:02 DST=188.8.131.52 LEN=60 ID=41883 PROTO=TCP SPT=60704 DPT=443
Oct 01 19:00:02 DST=184.108.40.206 LEN=60 ID=49753 PROTO=TCP SPT=60702 DPT=443
Oct 01 15:00:01 DST=220.127.116.11 LEN=60 ID=4622 PROTO=TCP SPT=56820 DPT=443
Oct 01 15:00:01 DST=18.104.22.168 LEN=60 ID=41882 PROTO=TCP SPT=60704 DPT=443
Oct 01 15:00:01 DST=22.214.171.124 LEN=60 ID=49752 PROTO=TCP SPT=60702 DPT=443
Oct 01 14:32:13 DST=126.96.36.199 LEN=84 ID=239 PROTO=ICMP TYPE=8 CODE=0 ID=20491 SEQ=0
Oct 01 14:32:08 DST=188.8.131.52 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.
19:00:01 info /usr/sbin/cron: (root) CMD (nethist_stats.lua)|
19:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/get-api-crl)
19:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/rainbow_button_sync.sh)
19:00:01 info /usr/sbin/cron: (root) CMD ( /usr/bin/notifier)
19:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/registration_code.sh)
19:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/contract_valid.sh)
19:00:02 err server_uplink: Failed to download contract status
20:00:01 info /usr/sbin/cron: (root) CMD (nethist_stats.lua)
20:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/updater-supervisor -d --rand-sleep)
20:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/rainbow_button_sync.sh)
20:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/contract_valid.sh)
20:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/get-api-crl)
20:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/registration_code.sh)
20:00:01 info /usr/sbin/cron: (root) CMD ( /usr/bin/notifier)
20:00:02 err server_uplink: Failed to download contract status
20:00:36 err server_uplink: Failed to get registration code
21:00:01 info /usr/sbin/cron: (root) CMD (nethist_stats.lua)
21:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/registration_code.sh)
21:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/rainbow_button_sync.sh)
21:00:01 info /usr/sbin/cron: (root) CMD (/usr/share/server-uplink/contract_valid.sh)
21:00:01 info /usr/sbin/cron: (root) CMD (/usr/bin/get-api-crl)
21:00:01 info /usr/sbin/cron: (root) CMD ( /usr/bin/notifier)
21:00:01 err server_uplink: Failed to download contract status
21: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 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.
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).
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.
There are three different generations of the Omnia router. See what they look like at doc.turris.cz/doc/en/howto/turris_versions
Turris offers to answer questions emailed to info at turris.cz
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.
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).
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.