DMZ Firewall

The DMZ solution is used to protect a separate network of public IP addresses. This differs from other types of network paradigms on ClearOS because outside addresses are used but are behind ClearOS as a firewall. Typically, a third network card is used exclusively for the DMZ network or a separate VLAN can be used. IP addresses behind a DMZ are routed as opposed to having Name Address Translation (NAT) applied to them. This module is only useful if you have more than 1 block of IP addresses from your ISP or the block that you have can tolerate being split into two. Either way, you must coordinate with your ISP so that they send the routes to the DMZ network to your ClearOS server.

The term 'DMZ' (or Demilitarized Zone) is related to the military use of a area of land in which hostility remains even after a conflict. In computing terms, it is a logical area of a network that is somewhere in between the paradigm of a LAN and a WAN network.

The firewall of ClearOS is able to handle the DMZ paradigm which consists of directly assigning public IP addresses to servers that reside behind the ClearOS firewall. As with the NAT firewall, ports are opened to allow outside access to the servers.

Unlike the LAN paradigm, however, servers in the DMZ cannot arbitrarily access client workstations or other servers except through special provisioned ports called 'pinholes'. A pinhole differs from a NAT or incoming firewall rule in two ways:

  • No NAT is applied, the server merely routes between a private and public network for which ClearOS is only aware.
  • Pinholes are not open to the world but only to servers on the DMZ

The advantage of this paradigm is that if any machine on the DMZ is compromised, it can only access devices also on the DMZ or LAN devices through pinholes.

It should be noted that DMZs give the same level of stateful packet inspection as do NAT'd connections. So, while the notion that these servers are using public IPs may cause one to have concern, the level of security is heightened with this model because of the segregation of services. Outside NAT connections to LAN interfaces place the same vulnerabilities as are present in a DMZ but the key difference is that not all your eggs are in one basket with the DMZ model.

When You Should NOT use DMZ

  • If you are configuring a few extra public IPs (not a whole network), then go to the 1 to 1 NAT section of the User Guide. DMZs require full subnets that are distinct from the subnet your ClearOS server uses to face the internet.
  • If you are configuring a separate private network (192.168.x.x or 10.x.x.x), then investigate Hot LANs in the IP Settings section of the User Guide. DMZs cannot provide NAT. If you are looking to segregate some traffic from your LAN but are using a private IP subnet, you will want to use HotLANs. A good example is a public WIFI network that you offer users who visit your site.


If your system does not have this app available, you can install it via the Marketplace.

You can find this feature in the menu system at the following location:



Network Configuration

Before you can use the DMZ firewall configuration, you need to configure one of your network cards or a VLAN on one of your network cards with the DMZ role. In our example, we used the network settings tool to configure a third network card (eth2) with the following:

  • Role: DMZ
  • IP Address: 216.338.245.17
  • Netmask:
  • Network: 216.338.245.16/28

All the systems connected to this third network card can then be configured with an IP address in the 216.338.245.18 to 216.338.245.30 range. Each of the devices must use the ClearOS address of 216.338.245.17 as their default gateway.

The IP address used in the example is bogus. You should obtain a valid subnet from your ISP or from ARIN in order to use the DMZ feature. In addition, your ISP must route the subnet to ClearOS in order for the path to be valid to and from your devices in the DMZ.

Incoming Connections

By default, all inbound connections from the Internet to systems on the DMZ are blocked (with the exception of the ping protocol). You can permit connections to systems on the DMZ by allowing:

  • all ports and protocols to a single public IP
  • all ports and protocols to the whole network of public IPs
  • a specific port and protocol to a single public IP

When setting up specific ports or protocols you are allowed to make multiple rules that are destined for the same IP address.

It is strongly recommended that all machines in the DMZ run their own firewalls.

Pinhole Connections (DMZ-to-LAN)

Pinholes are communication avenues for DMZ to LAN traffic. The default behavior is to block all traffic originating on the DMZ to the LAN. The default behavior is also to allow ALL traffic originating from the LAN to the DMZ. This means that workstations and servers on the LAN can initiate communication to the DMZ hosts any time they wish but the only messages from the DMZ back to the LAN are those that are responses to those communications or initiated communication where a pinhole exists.

An example of this communication would be a web server that uses a database server on a LAN. Say you wanted your webserver to be on a DMZ instead of being on a LAN. You have several reason for this. Perhaps you believe that the software for the website might not always be up to date or you believe that hackers will primarily target exploits on your very public facing web server. Placing this server on the LAN knowing that the server may eventually be compromised is a risk you do not want to take. The database of this server, however, is on a machine that has no public facing services. The only requirement it has is that the web server needs to talk to it using a non-privileged account using the database port. Placing this server behind the security of your LAN environment makes sense. By opening a pinhole for the database port between the web server and the and database server, you are able to have a fully functioning segregation of risk zones.


content/en_us/7_ug_dmz.txt · Last modified: 2018/06/11 08:48 by nickh