Configure Windows netsh Firewall for MongoDB
On Windows Server systems, the
netsh program provides methods for managing the Windows Firewall. These firewall rules make it possible for administrators to control what hosts can connect to the system, and limit risk exposure by limiting the hosts that can connect to a system.
This document outlines basic Windows Firewall configurations. Use these approaches as a starting point for your larger networking organization. For a detailed over view of security practices and risk management for MongoDB, see Security.
Windows Firewall documentation from Microsoft.
Windows Firewall processes rules in an ordered determined by rule type, and parsed in the following order:
Windows Service Hardening
Connection security rules
Authenticated Bypass Rules
By default, the policy in Windows Firewall allows all outbound connections and blocks all incoming connections.
Given the default ports of all MongoDB processes, you must configure networking rules that permit only required communication between your application and the appropriate
The configuration changes outlined in this document will create rules which explicitly allow traffic from specific addresses and on specific ports, using a default policy that drops all traffic that is not explicitly allowed.
You can configure the Windows Firewall with using the
netsh command line tool or through a windows application. On Windows Server 2008 this application is Windows Firewall With Advanced Security in Administrative Tools. On previous versions of Windows Server, access the Windows Firewall application in the System and Security control panel.
The procedures in this document use the
netsh command line tool.
This section contains a number of patterns and examples for configuring Windows Firewall for use with MongoDB deployments. If you have configured different ports using the
port configuration setting, you will need to modify the rules accordingly.
This pattern is applicable to all
mongod.exe instances running as standalone instances or as part of a replica set. The goal of this pattern is to explicitly allow traffic to the
mongod.exe instance from the application server.
This rule allows all incoming traffic to port
27017, which allows the application server to connect to the
Windows Firewall also allows enabling network access for an entire application rather than to a specific port, as in the following example:
You can allow all access for a
mongos.exe server, with the following invocation:
mongos.exe instances provide query routing for sharded clusters. Clients connect to
mongos.exe instances, which behave from the client’s perspective as
mongod.exe instances. In turn, the
mongos.exe connects to all
mongod.exe instances that are components of the sharded cluster.
Use the same Windows Firewall command to allow traffic to and from these instances as you would from the
mongod.exe instances that are members of the replica set.
Configuration servers, host the config database that stores metadata for sharded clusters. Each production cluster has three configuration servers, initiated using the
mongod --configsvr option.  Configuration servers listen for connections on port
27019. As a result, add the following Windows Firewall rules to the config server to allow incoming and outgoing connection on port
27019, for connection to the other config servers.
|||You also can run a config server by using the
For shard servers, running as
mongod --shardsvr  Because the default port number is
27018 when running with the
shardsvr value for the
clusterRole setting, you must configure the following Windows Firewall rules to allow traffic to and from each shard:
<ip-address> specification with the IP address of all
mongod.exe instances. This allows you to permit incoming and outgoing traffic between all shards including constituent replica set members to:
Furthermore, shards need to be able make outgoing connections to:
Create a rule that resembles the following, and replace the
<ip-address> with the address of the config servers and the
|||You can also specify the shard server option with the
|||All shards in a cluster need to be able to communicate with all other shards to facilitate chunk and balancing operations.|
Changed in version 3.6: MongoDB 3.6 removes the deprecated HTTP interface and REST API to MongoDB.
This section contains a number of basic operations for managing and using
netsh. While you can use the GUI front ends to manage the Windows Firewall, all core functionality is accessible is accessible from
To delete the firewall rule allowing