Publishing Internal APIs from DMZ Without Direct LAN Connections: Five Tested Architectures

When an API gateway is placed in the DMZ and corporate security policy prohibits any connections from the DMZ into the internal LAN, the most obvious proxying pattern becomes impossible. Business requirements nevertheless demand that consumers receive synchronous HTTP responses, making a full rewrite of integration contracts prohibitively expensive.

Over the past year the team at Neoflex evaluated five architectural options on the NEOMSA APIM platform, which is built on WSO2 components including the gateway, Micro Integrator, and developer portal. Three patterns reached working laboratory environments, one underwent full load testing, and the remaining two were validated through architecture reviews and security approvals.

Variant 1: Custom request-reply over Kafka

Kafka is deployed in the DMZ. The gateway writes requests to a topic; an internal Micro Integrator instance connects outbound to consume them, invokes the target system, and publishes replies to a second topic. Because Kafka lacks native reply-to semantics, the team implemented correlation, partition-based routing, dead-letter handling, and offset management in approximately 2,500 lines of Java packaged as a custom mediator. The solution works but introduces significant maintenance obligations and removes centralized policy enforcement.

Variant 2: JMS request-reply with ActiveMQ Artemis

Replacing Kafka with ActiveMQ Artemis eliminates all custom code. Both sides use standard JMS mediators inside Micro Integrator. The broker handles correlation identifiers, message expiration, and selective consumption. Load tests demonstrated a sustained 50 requests per second with 95th-percentile latency near 100 ms. Limitations include the inability to stream large or unknown-size responses and the requirement for idempotency keys on state-changing operations.

Variant 3: Reverse HTTP via HAProxy

An internal node initiates a persistent HTTP/2 connection to the DMZ gateway; roles are then reversed so the gateway treats the tunnel as an upstream. No DMZ-to-LAN firewall rule is required, no custom code is written, and the call remains ordinary synchronous HTTP. The mechanism is still marked experimental in HAProxy 2.9+, requiring careful configuration of connection reuse and keep-alive parameters.

Variant 4 & 5: Dual gateways with narrow DMZ-to-LAN rule

When security permits a tightly scoped rule allowing mTLS-authenticated traffic on specific ports, two simpler topologies become viable: a single management plane controlling gateways in both zones, or two independent NEOMSA APIM installations. Both preserve full policy, throttling, and key-management capabilities in one administrative domain.

The decisive question for any organization facing the same constraint is whether a narrow DMZ-to-LAN firewall exception with mutual certificate authentication can be obtained. The answer immediately eliminates or validates half of the candidate architectures.