Manage OPNsense firewalls behind NAT, CGNAT and mobile links
Central management only works if it can reach the firewall. At branch offices, customer sites or LTE connections that is often not the case. This guide explains what the OPNexus management tunnel is for, how it works and where its limits are.
The problem: the firewall cannot be reached from outside
OPNexus manages a firewall through its API, so it calls an address such as https://firewall/api/…. In your own network or over a site-to-site VPN that is no problem. At many sites it is:
- The branch uses an ordinary DSL or cable line with a router in front, where nobody can or may forward ports.
- The site uses mobile data (LTE/5G) or a connection with CGNAT and has no public address of its own.
- The firewall sits at a customer, and the management interface must not be exposed to the internet.
The firewall can reach the internet, but nobody can reach it from outside.
The usual workarounds and their drawbacks
- Exposing the web interface to the internet: The management is then reachable by anyone who finds the address. With CGNAT it is not even possible.
- A site-to-site VPN per site: That works, but has to be set up and maintained by hand for every firewall and carries more than management needs.
The solution: the firewall dials in by itself
The management tunnel reverses the direction. A WireGuard hub runs on the OPNexus server. Each firewall connects to this hub on its own initiative (outbound, which works behind any NAT). The result is a small private network in which every firewall has a fixed address, for example 10.99.0.2. OPNexus reaches its API at that address.
From then on the firewall behaves like any other: roll out rules with preview and automatic rollback, plan updates, fetch backups and logs, check the security posture. Pinning the firewall's certificate works through the tunnel as well.
An example
You look after five sites. Two of them you can reach directly; three are branches behind DSL routers or on LTE.
- Switch the hub on at the OPNexus server.
- For each of the three branches, choose “Add firewall” in OPNexus. It assigns a tunnel address and a pre-shared key of its own and shows the values to copy.
- Enter these values in the respective OPNsense under VPN › WireGuard, once, and remotely if need be.
- Add the firewalls as hosts using their tunnel addresses.
After that all five sites are managed the same way, and nothing at a branch needs to be reachable from the internet.
What you need
- The OPNexus server itself must be reachable from the internet on one UDP port (default 51820): a port forward on the server's router, or a server with a public address. The effort sits in one place instead of at every branch.
- The hub is an optional container (
COMPOSE_PROFILES=overlay) and needs the WireGuard kernel module, which every current Linux kernel ships. - On the firewall you create a local WireGuard instance, the peer (the hub) and a rule that lets the hub reach the web interface. OPNexus shows the steps with all values filled in.
How secure is it?
- No connections from the firewalls to OPNexus: The hub accepts no new connections from the firewalls. A compromised site reaches neither OPNexus nor other sites.
- No forwarding between firewalls: The hub does not route between sites or into the server's internal network.
- A key of its own per firewall: Every firewall has its own pre-shared key. Deleting it in OPNexus removes it from the hub immediately.
- Management only: OPNexus reaches the firewalls solely into the tunnel network through an internal proxy that is not reachable from outside.
Limits
- The tunnel is not a site-to-site VPN. The sites' user traffic does not run over it.
- OPNexus does not perform the first setup on the firewall itself, because it cannot reach the firewall yet.
- Firewalls in the tunnel network are addressed by IP address, not by DNS name.
- If all your firewalls are reachable anyway by LAN, site-to-site VPN or a public address, you do not need the tunnel. That is why it is off by default.
Frequently asked questions
Do I need the management tunnel for firewalls on the same network?
No. It is meant for firewalls OPNexus could not otherwise reach, for example behind NAT, CGNAT or a mobile link. Anything reachable by LAN, VPN or a public address is added as usual.
Does a port have to be opened at the branch?
No. The firewall connects outward by itself. Only one UDP port at the OPNexus server has to be reachable.
Does all of the branch's traffic go through the tunnel?
No. The tunnel carries only OPNexus's management traffic, not the sites' user traffic.
What happens if a firewall is compromised?
The hub accepts no new connections from the firewalls and forwards nothing between sites. A hijacked site therefore reaches neither OPNexus nor other firewalls. Its key can be removed in OPNexus with one click.
Try OPNexus
Free, self-hosted, source available. Installed in a few minutes.