I have a web service I need to expose on the DMZ for external communication. The web service communicates directly with a critical database that sits on an internal net.

Current solution

This is currently solved by having a service exposed in the DMZ, the endpoint is secured using a cert and it's using https. As a request is received the service places in on a in-memory queue structure. An internal service is then responsible for keeping an outgoing TCP channel open that looks for messages on the external queue and making sure that the external service posts those to the internal database using the now open outgoing TCP-channel. This is seen as more securely as it doesn't require the firewall to open for incoming traffic, only outgoing from the internal service.

What's the optimal solution?

My question is however if it is more secure and then why? Couldn't just the firewall be configured to restrict incoming traffic from only the server in the DMZ and make it basically as secure?

What's the de facto solution for these kind of scenarios?

1 Answer 1


Normally, you'd build a solution with an edge gateway, whereby the dangerous zone (WAN) hits your gateway, and that gateway forwards traffic through to the DMZ. This is best achieved with a physical hardware solution.

There are multiple ways of doing this, but my preferred method is to have a dedicated edge gateway that sits outside the DMZ, which then VPNs into the DMZ. The VPN endpoint inside the DMZ can be configured to limit the traffic coming through. The edge gateway essentially acts as a transparent proxy, passing requests through to the target server inside the DMZ. You can achieve this with most load balancing products, either as dedicated appliances or virtualised solutions.

This has the following benefits:

  • The WAN-facing device is outside the DMZ.
  • Everything going in and out of the DMZ is encrypted, authenticated, and integrity checked.
  • The edge gateway can provide inline NIDS / NIPS and stateful firewall, thus allowing you to block bad traffic before it even enters the DMZ.
  • You have multiple layers of network security control: the edge gateway's firewall and forwarding rules, the VPN endpoint's security settings, and the firewall on the web service box.
  • You can detect and block outbound connections (e.g. for mitigating reverse shell) on multiple layers of the network.
  • Compromising the gateway doesn't immediately put the attacker in a privileged position within the DMZ, since they're limited to what the VPN allows.
  • Great answer but this isn't really possible for my solution as the DMZ already is public facing.
    – Riri
    Oct 16, 2013 at 12:43
  • 2
    ... why is your DMZ public facing? That kinda negates the idea of it being a DMZ.
    – Polynomial
    Oct 16, 2013 at 12:44
  • @Polynomial this is an interesting approach - so do you have two hardware appliances in place? WAN | -- VPN -- | DMZ? (note that the | would represent a firewall)
    Oct 16, 2013 at 18:02
  • @DKNUCKLES The VPN endpoint doesn't have to be a hardware appliance, since it can run as a jailed or sandbox service on another box. The gateway is definitely a dedicated appliance.
    – Polynomial
    Oct 17, 2013 at 8:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .