sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-04-16 07:26:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update client-on-mikrotik-router.mdx (#353)

Browse Source 
* Update client-on-mikrotik-router.mdx

* Update client-on-mikrotik-router.mdx

Further refinements.
This commit is contained in:
Hammy Havoc
2025-06-03 07:38:31 +01:00
committed by GitHub
parent ef189731f5
commit 78830d8e09
1 changed files with 19 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
src/pages/how-to/client-on-mikrotik-router.mdx
View File

@@ -12,26 +12,23 @@ Running NetBird on MikroTik router or CHR enables cost-effective remote access t
without the need for additional hardware. In some usecases this can greatly simplify the setup and eliminate the need for additional infrastructure.
### Branch offices
Not all remote locations have a server room or a similar setup where they can just throw in an additional machine to run Netbird.
Think of small shops or branch offices that barely have a network cabinet to fit a switch and a router.\
Running Netbird directly on a router allows us to have remote access to perform basic network management and monitoring
without having to maintain an additional machine for Netbird router, or even worse - using one of the business-critical Netbird clients as a router. \
Not all remote locations have a server room or a similar setup where they can deploy an additional machine to run NetBird, i.e. small shops or branch offices that barely have a network cabinet to fit a switch and a router.
Running NetBird directly on a router allows us to have remote access to perform basic network management and monitoring without having to maintain an additional machine for NetBird router, or even worse—using one of the business-critical NetBird clients as a router.
The idea is that all computers on the network would still run clients, and this container would only be used for infrastructure management, monitoring
and maybe one or two small camera streams.
Note that container routing in RouterOS is currently very CPU-bound and is likely not good enough for massive file transfers, database connectivity
nor proper camera streaming.
Note that container routing in RouterOS is currently very CPU-bound and is likely not good enough for massive file transfers, database connectivity nor proper camera streaming.
### Field routers
For companies with field teams operating in remote areas, the use of MikroTik routers is a game-changer. These routers ensure connectivity without the reliance on field infrastructure, a unique advantage that sets them apart.
Think construction sites, pop-up events, field support teams for vehicles or industrial equipment, etc.\
Team members would still run NetBird on computers and phones, but a separate IT or infra team needs to be able to remotely manage MikroTik devices
to help with unpredicted issues in the field. For example, reconfigure the router to piggyback the entire network over the location's guest Wi-Fi or quickly switch between
that and 4G or satellite backup, depending on the type of failure.\
Traditionally, we would always have 4G in routers for minimal management connectivity and then run CHR in a cloud VM. Those routers would all start
VPN tunnels to the cloud VM so the IT team can connect to the router if needed. On top of that, we would need an additional NetBird router in the cloud to enable
remote access from NetBird to that cloud router and NAT to remote devices.\
Running NetBird directly on field routers removes the need for a lot of complexity because there's no longer a need for CHR to serve as a VPN concentrator or
a dedicated VM to route NetBird clients to MikroTiks.
For companies with field teams operating in remote areas—such as construction sites, pop-up events, or field support for vehicles and industrial equipment—MikroTik routers are a game-changer. They provide reliable connectivity without depending on on-site infrastructure, offering a distinct advantage that sets them apart.
Team members would still run NetBird on computers and phones, but a separate IT or infra team needs to be able to remotely manage MikroTik devices to help with unpredicted issues in the field. E.g., reconfigure the router to piggyback the entire network over the location's guest Wi-Fi, or quickly switch between Wi-Fi, backup cellular or satellite, depending on the type of failure.
Traditionally, we would always have cellular modems in routers for minimal management connectivity and then run CHR in a cloud VM. Those routers would all start VPN tunnels to the cloud VM so the IT team can connect to the router if needed. On top of that, we would need an additional NetBird router in the cloud to enable remote access from NetBird to that cloud router and NAT to remote devices.
Running NetBird directly on field routers removes the need for a lot of complexity because there's no longer a need for CHR to serve as a VPN concentrator or a dedicated VM to route NetBird clients to MikroTiks.
## Limitations
<Note>
@@ -85,11 +82,11 @@ This assumes our NetBird subnet is `100.80.0.0/16`.
/ip/route/add dst-address=100.80.0.0/16 gateway=172.17.0.2
```
We'll also want to add appropriate in, out, and forward rules, but those vary depending on the network setup, so we won't cover them in this guide.
We'll also want to add appropriate in, out, and forward rules, but those vary depending on the network setup, so are not covered by this guide.
We should also allow remote DNS queries from the container to the router's DNS server.
Just also make sure that router's firewall rules are set to block external access to DNS ports and also allow access to DNS ports from containers.
This is out of this guide's scope but it's important to mention because we'll be setting container's resolvers to router's IP addresses.
Ensure the router's firewall rules are set to block external access to DNS ports, and also allow access to DNS ports from containers.
This is beyond the scope of this guide's, though important as we'll be setting container's resolvers to router's IP addresses.
Enable container functionality logging in RouterOS and configure DockerHub registry cache on the external disk.
This assumes that our USB drive is mounted as `/usb1`:
@@ -130,8 +127,7 @@ Create the container and trigger image pull from DockerHub:
Note that we had to set container's hostname to something other than router's identity because RouterOS doesn't allow hostname conflicts.\
We have also set container's DNS resolver to router's DNS server. Feel free to tweak this if needed.
Our container is now ready and container image pull from DockerHub should have been triggered. We can check the RouterOS logs to see if the pull was successful
and we should see that RouterOS created our image cache directory in `/usb1/pull`.
Our container is now ready and container image pull from DockerHub should have been triggered. We can check the RouterOS logs to see if the pull was successful and we should see that RouterOS created our image cache directory in `/usb1/pull`.
### Start the container
We can verify that the container is created by running
@@ -139,13 +135,13 @@ We can verify that the container is created by running
/container print
```
And finally we can start it using the appropriate number from the print command:
We can now start it using the appropriate number from the `print` command:
```shell
/container start number=0
```
At this point we should see the container in our NetBird dashboard and we should be able to create routes through it in NetBird.
So, hop on to NetBird dashboard and create a route through the container to the router's bridge IP address.
Via the NetBird dashboard, create a route through the container to the router's bridge IP address.
Address will be 172.17.0.1/32 and routing peer will be our container. Don't forget to disable NAT on this route.