Many WISP operators face the same challenge:
Remote sites without public IP addresses
Routers behind CGNAT
Changing WAN IPs
Difficult remote management across multiple locations
Avoiding exposing MikroTik management ports directly to the Internet
TunGuard is an open-source userspace WireGuard VPN server that simplifies connecting remote MikroTik routers back to a central server.
The workflow is simple:
Install TunGuard on your VPS or server
Generate a MikroTik RouterOS configuration script
Import the script on your router
The router establishes a VPN connection back to your server
Once connected, each router receives a private VPN address that can be used for management.
Example:
TunGuard Server
10.100.0.1
MikroTik Tower 1
10.100.0.2
MikroTik Tower 2
10.100.0.3
Your management traffic goes through the private VPN network instead of requiring a public IP on every router.
Features:
Userspace WireGuard implementation
No kernel WireGuard module required
MikroTik RouterOS v7 support
Web dashboard for peer management
Automatic client configuration generation
REST API for integrations
Optional SSH gateway
Self-hosted and open source
This can be useful for WISPs managing multiple towers, customer sites, or remote MikroTik deployments where public IP availability is limited.
I would like to hear from the MikroTik community:
How are you currently managing MikroTik routers behind CGNAT?
Would a self-hosted WireGuard management layer simplify your deployments?
What features would you like to see added for WISP environments?
Remote sites are managed similarly albeit via ipsec tunnels, and no need to install anything on a server. Local gear directly, since the network is not exposed.
That is a valid approach. IPsec works well for many traditional site-to-site deployments.
The idea behind TunGuard is a little different it is not trying to replace IPsec or just be another WireGuard management panel. WireGuard is the transport layer, but TunGuard adds the operational layer around it.
The focus is making remote connectivity easier to deploy and manage:
userspace VPN engine that runs as a portable service
automatic peer provisioning
MikroTik RouterOS script generation
private management networks for devices behind CGNAT
optional SSH jump host access for remote management
backup and migration workflows so the VPN environment can be moved to another server easily
For WISP environments, the challenge is often not creating one tunnel it is managing hundreds of remote routers consistently without exposing management ports or manually maintaining every configuration.
The goal is to make remote network management simpler. IPsec is a great tool, and adding IPsec automation is something that could fit naturally as another connection type in the future.
(Note also, that my ipsec is used for more than just managememt. The main use it to permit access to gear masked by the 3rd party NAT (cameras) for both management and secure operation/recording. All other traffic flows via the NAT . . . )
Fair point. IPsec is a proven solution and works well for many WISP deployments.
The problem we are looking at is less "how do you make one tunnel" and more "how do you manage hundreds of remote devices consistently." That is the layer TunGuard is trying to simplify.
Thanks for the discussion these are exactly the kinds of use cases that help shape the project.
My setup would scale as well. Every remote sets a tunnel with a fixed IP, and WinBox (or whatever) simply connects to the correct IP . . . No DHCP or other random IP BS.
The scripts/commands to setup would be 95%+ fixed, not much more that IP would change, and could easily be built into an initial config.
There is the overhead of the tunnels, but since, by definition, coming from behind a NAT, that side has to initiate, that would seem inevitable.
I also am a bit "old school" though . . . 30+ years working in/with the Fortune 100, I tend to categorically refuse tools which enourage an admin to be clueless about a config, and unable to resolve issues. (I was once asked when taking over a *nix group, what admin toolkit I preferred. My response was "vi" . . . nothing more is needed, at least by the senior folks. And I made a good living early on fixing things that admin tools broke . . . ) My view is that if an admin can't config/debug at the lowest level, I have an incompetent admin (at least senior ones, if tiered) . . .
Not that this tool may not have a place. I just find this stuff simple to begin with . . . (and def not trying to dump on it . . . )
Thanks for the feedback. Based on the discussion, we've added native IPsec automation as an alternative deployment method.
If you already have an IPsec gateway (MikroTik, CHR, strongSwan, etc.), you can now generate a RouterOS IPsec provisioning script directly from the dashboard no TunGuard server required. If you prefer the additional provisioning and management features, TunGuard WireGuard remains available as the other deployment option.
Appreciate everyone sharing how they're managing their networks it helped shape this addition.
)