Feature Request: Zero Trust Tunnel - Cloudflare Version

RouterOS RouterOS beta
1

https://www.youtube.com/watch?v=BbDnBxlBTdY&t=134s

After watching this video it came rapidly clear to me that this feature touches functionality used by just about every config I have seen/worked on in these forums.
In other words, one should not use the word niche but more aptly mainstream to describe zero trust cloudflare tunnel. What do I mean…?
Well we are talking about dstnat port forwarding to servers on the local LAN.

The method Normis describes seems relatively painless, to do the one thing that is not really possible on MT devices which is protect the public WANIP. MT devices are not that good at ddos and other edge router type functionalities and YET, I see bloated configs trying to contort the MT device into a magic box of security which amounts to not much.
Normis describes a methodology that surpasses anything the MT can do, besides creating source address lists for incoming users, which does increase security, but very rarely does this help the server admin who is unable or unwilling to take that step or its not possible in their scenario, and which still makes the public IP known.

Due to the sheer volume of users with servers, my contention is that this functionality should not be hidden in dockers/containers, limited to a certain number of devices AND with all its added complexities but should be mainstream on the menu. I would hazard a guess that more people will use this functionality than wireguard which is not hidden in a container/docker package.
Heck make it an optional package if not part of the normal ROS package.

Food for thought.

2

Hmm, 132 gutless viewers LOL.

and MT by the way for gods sakes already add a client re-connect feature to MTs implementation of Wireguard, I just had to inform another person of scripts as a work around to your failure to address a known issue. Have some initiative for a change! :slight_smile: Now that you have won some awards doesnt mean ignore the users… How many are using wireguard? YOU DO the math.
How many are using SERVERs? You do the math ( hint not just ARM users ;-PPP )

Me thinks MT staff need a math lesson… https://www.youtube.com/watch?v=NSfYKaJSawI&t=940s

3

@anav … excellent suggestion and I agree that MT should fix the WG issue … long overdue …

4

When containers first came out in some 7.x betas, it was on all MT platforms. I still think that’s a good idea. For exactly things like this…

In this case, the Cloudfire container is distroless so it just need the C runtime lib for the MIPS/TILE/etc for a working image (e.g. NOT a Ubuntu for TILE). So I can’t imagine it be that difficult for Mikrotik to compile the image with the non-ARM platform’s glibc… that is if /container were exposed on non-ARM platforms.

5

So let me get this straight in order to have a more secure SERVING experience by making use of zero trust tunnel, not only do I have to buy a specific advice to get access to containers, Now you WANT me to create the potential of a very high security risk scenario by being forced to use containers to get access to this functionality. Sounds so counter - intuitive if you ask me…

Once again logic escapes MT…

you need physical access to the router to enable support for the container feature, it is disabled by default;
once the container feature is enabled, containers can be added/configured/started/stopped/removed remotely!
if the router is compromised, containers can be used to easily install malicious software in your router and over network;
your router is as secure as anything you run in container;
if you run container, there is no security guarantee of any kind;
running a 3rd party container image on your router could open a security hole/attack vector/attack surface;
an expert with knowledge how to build exploits will be able to jailbreak/elevate to root;

6

To be clear, I wasn’t advocating against making this a package. I too like to see more “extra-packages” (over more containers examples). But I just don’t think that’s the direction Mikrotik is going…

So my point is if Mikrotik is going to be promoting container usage…they should try to make available on all platforms.

On Cloudflare’s docker image… it’s actually pretty efficiently built, so it’s largely just the “exe” (vs. containers that are based on a a full Ubuntu/etc distro). So I’m not sure the attack profile changes much whether it’s a container or an “extra-package”. Mikrotik doesn’t allow privileged containers, while bugs may expose things - that’s true of all code that lives on RouterOS. By using a cloud service for your traffic, there is whole different set of risks to consider beyond RouterOS package styling…

7

I get your point AMMO as zero tunnel uses a third party and its inherent risks.

8

@mikrotik, if the reason not to include this in regular ROS is the amount of code, then create a separate package please.

9

To be clear, I’d perfer if Mikrotik did release packages for cloudflare. I don’t use it today, but it sure does solve a lot of “advanced home” use cases. I think containers are “too fragile” and limited to ARM, which then makes using Cloudflare less useful if you can use it on ALL the Mikrotiks you may have…

Since I enjoy playing devil’s advocate. Do think cloudflared is bit more complex than it appears, while Normis’ YouTube shows the “tunnel”. It offers other things like “proxy-dns”, that acts as local resolver that then forwards DNS to cloudflare via DoH – which lives in same codebase as tunnel (and there are more features too). So I can see how it’s not simple to shove into a Mikrotik package since there are a lot of options to map into the RouterOS CLI…

I was only saying if Mikrotik ain’t going to do a package…they could at least allow containers on non-ARM. I get DockerHub won’t help with MIPS or TILE, but bazel image builder used by cloudflared likely more easily deal with MIPS or TILE since it’s distroless, it just need the TILE/etc linux kernel/glibc, NOT ubuntu/alpine/etc. That at least solve the all platform problem… And since cloudflared does have quite a few options, that does kinda work with the container cmd= method since you can cut-and-paste form Cloudflare’s examples when setting up various features on their admin webpages (which do have Docker instructions).

10

We are running almost everything through Cloudflare Zero Trust tunnel (and have been doing so for about a year). The tunnel in the modern day is entirely configured through the Cloudflare admin webpage, unless you are doing some weird/advanced things. There is a config file, but we’ve set up dozens of tunnels and haven’t had to edit the config file once. You are not going to need many options in the CLI, if any.

11

So in conclusion mducharm, do you agree that MT should make Zero Trust tunnel, if not part of the core ROS, at least available in a package. Do you also agree with AMMO that having such functionality will reduce the security risk self-imposed by users hosting servers on MT devices ??? Finally, do you agree that such functionality “FITS” with MTs ‘reputation’ of espousing excellent routing with concurrent security and good practices!

12

I would prefer an add on package for such a thing vs having to deploy a container, yes. I do not think it should be part of the core ROS as it is a third party solution, similar to ZeroTier, and so an add-on package would make the most sense.

13

Please show us tools for building containers for those platforms and working example.

14

Hi, coul I use ZTT without public IP address?

15

Yes, there is no need for a public IP for it. You can be behind multiple levels of NAT and it will still work.

16

I think my larger point, as a Mikrotik customer, while not a Cloudflare user, the offering looks solid & particular useful to “offload” security function that could never run on a common Mikrotik. You have other customers here saying they use it & I can see how Zero Trust native package cut @anav’s workload on the forum by 50%. While informative/useful and apparently inspiring…Normis’s video does gloss over multi-step process to enable container, which your customers can’t so easily skip (to then find a security disclaimer in the containers docs, while trying to set up a tunnel to internet).

Your current tunnel types (IKEv2, WG, L2TP, even PPTP) cover other cloud services (AWS, Azure, etc) and major VPN providers, but the unique in Cloudflare is it’s function are tied to their non-standard Zero Trust (Argo) tunnel. To me this, this looks to fills an opposite role of ZeroTier – centralization – but like ZeroTier, Zero Trust has it’s own tunnel. Similarly native support be very handy.

I just use your ARM platforms for new projects to avoid worrying about whether a feature is going to be support. But yeah your products last a long time! Lots of MIPSBE things still working for closer to a decade in my world BUT also fair to say time for an upgrade :wink:



I’m prone to oversimplification – I have no idea of the state of Linux toolchain for Tilera or xMIPSxE, which very well may be poor. Y’all did have container on other platforms in very early V7 alpha – so even if not immediately useful, maybe useful to someone more ambitious. Certainly not a project I’m looking to do, but the Mikrotik world is big.

But there are plenty of non-Docker ways to build a container image, see https://dev.to/thakkaryash94/how-many-ways-to-build-a-container-image-4g3p . Cloudflared and a lot of other containers use Google’s tools, https://github.com/GoogleContainerTools/distroless , which essentially reduce Alpine container base image even further. And less dependencies would increase the chance of the underlying code in a container compiling for Tilera/xMIPSxE

To me, the central question is how well does Go code compiles on TILE, MIPSBE, etc. That’s what matters whether you want to do a native package or container for cloudflared (since both cloudflared & most of the OCI/Docker tools too seem be in Go). But do think some C+±based application could be compiled into a container more easily, if RouterOS exposed the OCI interface for non-ARM. MetaROUTER used to run OpenWRT on V6 with MIPSBE after all, so I don’t think containers on more platform is a stretch.

17

You could just skip container and have a WASM shim on non-ARM – which Docker supports – so all you’d need to do is code to compile to WASM. I’d imagine they’ll be a WASM version of cloudflared, so another way to skin the cat. But a little off topic.

18

IMO, WASM is like of a poor man’s container or even more of a Kubernetes pod.

EDIT:
Because the WASM ecosystem is slimmed down by design, it’s perfectly suited to run in smaller environments, but all the dynamic dependencies are likely to be a challenge.

19

Lets focus on the art of the logical/reasonable/possible and that is MIKROTIK get working on adding a Zero Trust tunnel as an addon package item !!!

20

To add to your cause (which I already tried to do…), the token in the container run command poses some security concerns – any user can view it & export’ed config would expose it too. As a native package, the token could be “sensitive”.