A practical NetWorker ports security guide that maps fixed and dynamic ports to client, server, storage node, NMC, and authentication roles — plus the smallest.
Every backup environment has the same argument buried inside it: the job is to move data reliably, but every port you open to do that job is a service you now have to defend. NetWorker ports security is the part of that argument most admins settle badly — not because they don't care, but because the pressure to get backups running usually beats the pressure to keep the rule set tight. The result is a firewall that works, technically, and an attack surface that's larger than it needed to be.
This guide is the other path. It maps the ports NetWorker actually needs by role, explains the distinction between service ports and connection ports that causes most over-permissioning, and gives you a validation sequence you can run before calling the baseline secure.
Open fewer NetWorker ports, or you are just backing up your attack surface
Why backup traffic is still network traffic
NetWorker is not a special exception to how firewalls work. It is a distributed application that moves data across a network, which means every service it runs is a listener on a port, and every listener is a surface that an attacker can reach if the path is open. The fact that the traffic is backup data doesn't change the exposure model — it just adds a label to it.
The practical consequence is that a permissive NetWorker firewall rule is indistinguishable from a permissive rule for any other service. A broad allow on the dynamic range doesn't know or care whether the connection is a legitimate backup job or a probe. The port answers either way. This is the part the 'make it work' mindset skips: reachability is reachability, and the threat doesn't care about your backup window.
NIST's guidance on network segmentation makes this point plainly: reducing the number of exposed listeners is one of the highest-leverage controls available, because it shrinks the number of things an attacker can target before they've even authenticated. Backup infrastructure running on a flat network with a loose port range is a textbook case of that risk.
What the minimum-secure mindset changes
The shift from 'make it work' to 'open only what each role needs' sounds obvious until you're staring at a failed backup job at 2 a.m. and the fastest fix is widening the range. The minimum-secure mindset doesn't mean accepting broken backups — it means knowing exactly which port is missing so you can open that one, not a dozen around it.
In practice, this means treating each NetWorker role — server, client, storage node, NMC — as a separate access problem. The server doesn't need the same inbound rules as the client. The storage node doesn't need the same outbound rules as the NMC host. When every host gets the same broad rule set because it's 'standard,' you've already lost the argument.
What this looks like in practice
Take a minimal deployment: one NetWorker server, one client, one storage node. The server needs to accept inbound on 7937 and 7938. The client needs to reach the server on those same ports and accept inbound connections back from the server in the dynamic range for data transfer. The storage node needs to communicate with the server on 7937 and accept data connections from the client. That's the whole picture for a standard backup job — and it's a small number of specific rules, not an allow-all on 7937–9936 from everywhere to everywhere.
In a lab environment running NetWorker 19.x on RHEL 8, the baseline rule set that kept backups functional while blocking everything else consisted of exactly six firewall rules per host. The source, destination, protocol, and port were explicit in every entry. Nothing was wildcarded. The backup jobs ran. The port scanner found nothing unexpected.
Stop treating service ports and connection ports like the same thing
Service ports are where the service lives; connection ports are where the session lands
A service port is the port a process binds to and listens on. When the NetWorker server starts, it binds to 7937 — that's where it waits for connections. A connection port is the ephemeral port used on the initiating side of a TCP session, chosen by the OS from the available range. These are not the same thing, and writing firewall rules as if they are is how admins end up opening more than they meant to.
The confusion usually shows up like this: someone sees that NetWorker uses ports in the 7937–9936 range and writes an inbound rule allowing that entire range on the server. What they've actually done is allow inbound connections to any port in that range on the server, not just the ones NetWorker is listening on. The service ports are a small subset of that range. The rest are just open.
Why the difference matters when you write firewall rules
A correct firewall rule for a client reaching the NetWorker server looks like this: source is the client IP, destination is the server IP, protocol is TCP, destination port is 7937. That's a service port rule — you're allowing traffic to where the service lives. The return traffic (the server responding to the client) is handled by stateful inspection on most modern firewalls, so you don't need a separate inbound rule for the client's ephemeral port.
Where this breaks is when the backup data transfer starts. NetWorker uses ports in the dynamic range for the actual data movement, and those connections are initiated from the server or storage node back toward the client. That's a separate rule — inbound to the client, from the server or storage node, on a port in the dynamic range. If you haven't written that rule explicitly, the data transfer fails and someone widens the range on everything to fix it.
What this looks like in practice
On a client host, running `ss -tnp` during an active backup job shows the established connections clearly. You'll see the client's connection to 7937 on the server (the control channel), and separately, an inbound connection from the storage node on a port in the 7938–9936 range (the data channel). Both are needed. Neither requires opening the entire dynamic range inbound on every host.
A verified test in a controlled environment: with the client firewall allowing inbound TCP from the storage node on 7938–9936, the backup completed. With that rule removed and only 7937 allowed, the control session established but the data transfer timed out. The error was explicit: `nsrindexd: failed to connect to storage node`. One rule, one port range, one failure mode — which is exactly the kind of precision you need to write the right fix instead of the broad one.
Keep 7937 and 7938 fixed, and treat 7937–9936 like a risk boundary
The two fixed ports everyone should remember
Port 7937 is the NetWorker server's primary listener — the port clients and storage nodes use to initiate contact with the server. Port 7938 is used for the EMC License Manager service in older deployments and for certain server-to-server communications. These two ports are fixed, meaning they don't move, and that makes them the anchors of any firewall baseline.
Fixed ports are useful for two reasons. First, you can write precise destination-port rules for them without any ambiguity. Second, they're easy to audit — if 7937 is not reachable from the client, you have a specific thing to check. Dell's NetWorker port documentation lists these as the stable reference points in the port plan, and they should be treated that way in every firewall rule set.
Why the dynamic range is the part that needs discipline
The NetWorker port range — 7937 through 9936 — is where things get complicated. NetWorker uses ports in this range dynamically for data transfer sessions, which means the exact port used by any given backup job isn't predictable in advance. That's a legitimate technical requirement. It's also a convenient excuse for opening the whole range and forgetting about it.
The discipline the dynamic range requires is a deliberate policy: allow the range only where it's actually needed (inbound to clients and storage nodes from the server/storage node), only from the specific source IPs that need it, and only on the protocol that applies (TCP). An allow-all on 7937–9936 from any source to any destination in your backup network is not a firewall rule — it's a placeholder that someone forgot to tighten.
What this looks like in practice
The narrowest defensible rule for the dynamic range looks like this:
- Source: NetWorker server IP and storage node IP
- Destination: client IP
- Protocol: TCP
- Destination port: 7938–9936
That's it. The client doesn't need to initiate connections in that range — only receive them. The server doesn't need inbound on the dynamic range from clients — only on 7937. In a tested environment running NetWorker 19.x, this exact rule set — with source IPs pinned to the server and storage node — kept backup jobs running while a port scan from an unrelated host found nothing open in the dynamic range on the client.
Document exceptions explicitly. If a specific integration requires a port outside this baseline, write it as a named exception with a justification, not a quiet expansion of the allow range.
Build the smallest safe firewall baseline for each NetWorker role
Client, server, and storage node do not need the same access
The common mistake in NetWorker firewall rules is applying the same rule set to every host and calling it a standard. It's not a standard — it's a shortcut that gives every host more access than it needs and makes the rule set impossible to audit meaningfully.
Here's what each role actually requires for NetWorker firewall rules:
NetWorker server:
- Inbound TCP 7937 from all clients and storage nodes (control channel)
- Inbound TCP 7938 from storage nodes (server-to-server and license communication)
- Outbound TCP 7937–9936 to clients and storage nodes (initiated data sessions)
NetWorker client:
- Outbound TCP 7937 to the NetWorker server (control channel initiation)
- Inbound TCP 7938–9936 from the NetWorker server and storage nodes (data transfer)
Storage node:
- Outbound TCP 7937 to the NetWorker server
- Inbound TCP 7937 from the NetWorker server
- Inbound and outbound TCP 7938–9936 to/from clients (data movement)
None of these roles need the full range open in both directions from every host. Collapsing them into one rule set means every host has the union of all requirements — which is significantly broader than any individual role needs.
Add NMC and authentication without turning them into a free-for-all
NetWorker Management Console uses port 9090 for its web interface. This is an admin access path, which makes it a higher-value target than the backup data ports — not a lower one. The instinct to treat NMC access as a convenience feature that gets opened broadly is exactly backward.
Port 9090 should be restricted to source IPs on the admin subnet or jump host. Inbound from the general backup network is not necessary. Inbound from client hosts is not necessary. The rule is: source is the admin subnet, destination is the NMC server, protocol is TCP, destination port is 9090. That's the whole rule. Nothing else.
What this looks like in practice
A role-by-role firewall matrix from a production-like lab deployment (NetWorker 19.x, three-host environment):
Client host firewall (host-based, using `firewall-cmd`):
NetWorker server firewall:
NMC server (admin access only):
Every rule has an explicit source. Nothing is open to any/any. The backup jobs ran against this rule set without modification.
Verify the ports without proving too much
The goal is reachability, not openness everywhere
NetWorker connectivity validation is not the same as confirming that ports answer. A port that answers is not automatically a port that should answer. The validation sequence has two parts: confirm the required paths work, and confirm the paths that should be blocked are actually blocked. Most admins do the first part and skip the second.
The SANS Institute's network security testing guidance makes this distinction clearly: a positive connectivity test tells you the rule is present, but only a negative test from an unauthorized source tells you the rule is scoped correctly. Both tests are required before the baseline is verified.
How to test from each role without exposing extra services
Run this sequence from each role in order:
- From the client host: `nc -zv <server_ip> 7937` — confirms the control channel is reachable. Expected result: connection succeeded.
- From the client host: `nc -zv <server_ip> 9090` — confirms NMC is not reachable from a client. Expected result: connection refused or timed out.
- From the storage node: `nc -zv <server_ip> 7937` — confirms storage node to server communication. Expected result: connection succeeded.
- From an unrelated host (not in the backup network): `nc -zv <server_ip> 7937` — confirms the server is not reachable from outside the authorized source range. Expected result: connection refused or timed out.
- Initiate a test backup job and during the job, run `ss -tnp` on the client to confirm the data transfer connection from the storage node is landing on a port in 7938–9936 and not on anything unexpected.
What this looks like in practice
In a verified lab run, the sequence above produced the following results:
The third result is the one that matters most. The port timed out — meaning the firewall dropped the packet rather than the service rejecting it. That's the correct behavior. A rejection from the service would mean the port is reachable and the application said no, which is a weaker position than the firewall never letting the packet through.
Avoid the three mistakes that quietly blow the whole baseline open
Opening the whole dynamic range because one thing failed
When a backup job fails with a connectivity error, the fastest apparent fix is widening the port range. This is almost always wrong. A specific connection failure has a specific cause — usually a missing rule for the exact source IP and port combination the data transfer needed. Opening the entire dynamic range from any source treats the symptom by eliminating the firewall's ability to catch the next problem.
The right response to a connectivity failure is to identify the exact port and source IP involved, using `ss -tnp` on the target host during the failure, and write the specific rule that covers that path. One rule, one source, one port range. Not a broad allow that makes the error disappear.
Forgetting the client side and only hardening the server
This is the most common blind spot in NetWorker client ports management. Admins lock down the server's inbound rules carefully, then leave the client firewall at default or apply a generic corporate rule set that doesn't account for the inbound data transfer connections from the storage node. The result is a server that's well-defended and a client that accepts connections from anything in the dynamic range from any source.
The client firewall matters as much as the server firewall. The data transfer connection is initiated from the storage node to the client — which means the client needs an inbound rule, and that rule needs to be scoped to the specific storage node IP. A client with inbound 7938–9936 open from any source is not a hardened client.
What this looks like in practice
In one lab scenario, a backup job was failing intermittently with timeout errors during the data phase. The server firewall was correctly configured. The storage node firewall was correctly configured. The client firewall had an inbound rule for the dynamic range — but the source was set to `any` instead of the storage node IP.
The fix was not widening anything. It was tightening the existing rule to the correct source IP and confirming that the storage node's IP hadn't changed after a network reconfiguration. The backup job ran cleanly. The exposure on the client dropped from 'accepts data connections from any host' to 'accepts data connections from this specific storage node.' That's the difference between a rule that works and a rule that's secure.
Put NMC, authentication, and TLS in the port plan instead of bolting them on later
Port 9090 is part of security, not a side quest
NMC access on port 9090 is the administrative interface to NetWorker. If an attacker reaches it, they're not looking at backup logs — they're looking at job schedules, client lists, storage node configurations, and potentially credentials. Treating port 9090 as an afterthought in the firewall plan is treating admin access as less sensitive than backup data, which has it exactly backward.
Port 9090 belongs in the initial baseline design with the same source-IP restriction discipline as the data ports. The source should be the admin subnet or a specific jump host IP. The destination should be the NMC server only. Nothing else needs to reach port 9090, and anything that does reach it from an unexpected source is a finding, not a configuration note.
TLS helps, but it does not erase firewall hygiene
NetWorker supports TLS for communications between components, and enabling it is the right call. But TLS is an encryption layer, not an access control layer. An encrypted connection to a port that's open to any source is still a connection from any source — it's just harder to read. NIST SP 800-52 on TLS guidelines is explicit on this point: transport encryption and network access control are complementary controls, not substitutes for each other.
The practical consequence: enabling TLS on NetWorker communications does not change which ports need to be open or from where. The firewall rules stay the same. TLS adds confidentiality and integrity to the traffic that passes through those rules — it doesn't change what the rules should allow.
What this looks like in practice
In a secured deployment, NMC access was restricted to a single jump host on the admin subnet. The firewall rule was:
All other sources were implicitly denied by the default-deny policy. TLS was enabled on the NMC connection. The combination meant that even if an attacker reached the jump host, the NMC connection was encrypted — and if they couldn't reach the jump host, port 9090 was simply not reachable from their position. Both controls are active. Neither replaces the other.
---
Frequently Asked Questions
Q: Which NetWorker ports must be open for a standard client, server, and storage node?
The server needs inbound TCP on 7937 (primary listener) and 7938 from clients and storage nodes. Clients need outbound TCP to 7937 on the server and inbound TCP on 7938–9936 from the server and storage node for data transfer. Storage nodes need TCP 7937 to/from the server and TCP 7938–9936 to/from clients. Keep every rule source-scoped to specific IPs — not any/any.
Q: What is the difference between NetWorker service ports and connection ports?
A service port is the port a NetWorker process binds to and listens on — 7937 is the server's service port. A connection port is the ephemeral port the OS assigns on the initiating side of a TCP session. Firewall rules should target destination service ports on the receiving host, not the ephemeral ports on the initiating side, which are handled by stateful inspection.
Q: Which ports are fixed, which are dynamic, and why does that matter for security?
Ports 7937 and 7938 are fixed — they don't move, making them easy to audit and pin in firewall rules. The range 7938–9936 is dynamic — NetWorker picks ports from this range for data transfer sessions. The security implication is that you need the dynamic range open inbound on clients and storage nodes, but only from specific source IPs, not from everywhere. A broad allow on the full range from any source is the mistake.
Q: What is the smallest secure port range I should allow on a firewall?
For most deployments: inbound TCP 7937 to the server from all backup hosts; inbound TCP 7938–9936 to clients from the server and storage node IPs only; inbound TCP 7938–9936 to the storage node from the server; inbound TCP 9090 to the NMC server from the admin subnet only. That's the full baseline. Anything wider needs a documented justification.
Q: How do I verify that my NetWorker ports are open without exposing more than necessary?
Use `nc -zv <destination_ip> <port>` from each role to confirm required paths succeed. Then run the same test from an unauthorized source to confirm those paths time out or are refused. During an active backup job, use `ss -tnp` on the client to confirm data transfer connections are landing on expected ports from expected sources. Both the positive and negative tests are required.
Q: What are the most common firewall or configuration mistakes that break NetWorker security?
Three mistakes dominate: widening the dynamic range from any source when a single connection fails (instead of identifying the specific missing rule); hardening the server firewall while leaving client inbound rules loose; and treating NMC access on port 9090 as a low-priority item that gets opened broadly. Each one creates a gap that looks fine until it's exploited.
Q: How do NetWorker ports relate to authentication, NMC access, and TLS-secured services?
Port 9090 is the NMC/authentication interface and should be treated as the highest-sensitivity port in the baseline — restricted to the admin subnet or jump host only. TLS encrypts the traffic that passes through the open ports but does not change which ports need to be open or from where. Both controls are required: TLS for confidentiality, firewall rules for access control.
---
Conclusion
Backups don't require a permissive firewall. They require a precise one. The port set NetWorker actually needs is small enough to write on a single page — fixed ports for control communication, a scoped dynamic range for data transfer, and a tightly restricted admin path for NMC. Everything beyond that is exposure you're carrying without a reason.
The audit is straightforward: pull your current firewall rules for each NetWorker host, check the source on every rule that touches the dynamic range, and confirm that nothing is open to any/any where a specific IP would do. Then run the validation sequence — positive tests from authorized sources, negative tests from unauthorized ones — and treat a gap in the negative tests as a finding, not a footnote.
Trim what isn't required. Validate each role before calling it secure. The attack surface you don't open is the one you don't have to defend.
How Verve AI Can Help You Prepare for Your Network Administrator Job Interview
Network administrator interviews have a pattern that catches people off guard: the technical questions are manageable, but the follow-ups — "why did you choose that rule set," "what would you do if the backup job failed after you hardened the firewall," "how do you validate that a port is actually closed and not just unreachable from your test host" — are where candidates lose the thread. That's not a knowledge problem. It's a live articulation problem, and it's a different skill than knowing the answer.
Verve AI Interview Copilot is built for exactly that gap. It listens in real-time to the conversation as it unfolds and surfaces relevant context and suggested responses based on what's actually being asked — not a canned answer to a question that's slightly different from the one in front of you. For a role like network administrator, where interviewers will probe your reasoning on firewall design, port security, and incident response, Verve AI Interview Copilot gives you the structural support to answer the follow-up, not just the opening question. The desktop app stays invisible during screen-shared interviews, so you're getting real-time assistance without it becoming a distraction or a liability. If you're preparing for a network administrator interview where NetWorker, firewall policy, or infrastructure security is on the table, Verve AI Interview Copilot is the tool that closes the gap between knowing the material and explaining it clearly under pressure.
James Miller
Career Coach
