Internal Users Cannot Reach the Public ERP URL, and Two Rules Nobody Owns
A manufacturer with 240 staff publishes an ERP portal from a DMZ to about 60 business partners over HTTPS. The perimeter firewall has three zones - inside, DMZ and outside - and a rule set maintained by a contractor who has since left. External partners can log in normally. Internal staff typing the public URL get a connection timeout, although the internal DNS server correctly resolves the name to the public address. The nightly backup pulls 400 GB from the DMZ application server to an internal file server, and no rule for it can be found in the current configuration. A security review also finds TCP 3389 permitted from any outside address to a jump host in the DMZ, and a rule described as temporary, inside to DMZ on any service, created 14 months ago and still present. Logging is disabled on all rules.
1. Explain why internal staff time out on the public URL, and compare split DNS with hairpin NAT, including what hairpin NAT requires beyond the destination translation.
Read the worked answer
Why the timeout happens. The internal client resolves the public name to the firewall's outside address. Its SYN travels from the inside zone to the firewall, which receives it on the outside interface. Most rule sets have no rule permitting inside-to-outside-interface traffic for that service, and even where a destination translation exists, the return path is broken: the DMZ server's default gateway sends replies straight back to the client's inside address, so the client sees a SYN-ACK from an address it never sent a SYN to and discards it. The connection hangs until timeout.
Split DNS. The internal resolver returns the portal's private DMZ address instead of the public one. Traffic then flows inside-to-DMZ under a normal rule, no NAT trickery is involved, and troubleshooting stays simple. Cost: two data sources to keep in sync, and a certificate whose subject or SAN must cover both names - wildcard or multi-SAN certificates are usually needed.
Hairpin NAT (NAT reflection). The firewall must translate the destination to the DMZ address and translate the source to an address the DMZ server will route replies back through, typically the DMZ-facing interface of the firewall. Without that source translation, the return path bypasses the firewall and the handshake fails. So hairpin needs both DNAT and SNAT plus an explicit rule pair, and it consumes firewall sessions and CPU on every internal connection.
Recommendation: split DNS for staff, because it needs no NAT and is easier to audit. Keep hairpin only if some internal clients cannot use the internal resolver, such as devices pinned to a public resolver.
2. Rank the three security findings and set out the corrected rule set, with the reasoning for the order.
Read the worked answer
Ranking.
- RDP from any outside address to a DMZ jump host is the highest risk: it is an internet-exposed remote-control service with a history of pre-authentication vulnerabilities, and a DMZ host is one pivot away from the internal network.
- The 14-month-old any-service inside-to-DMZ rule is next: it defeats the purpose of the DMZ by allowing lateral movement and outbound abuse from any compromised internal host, and nobody owns it.
- Logging disabled everywhere is third in direct risk but first in remediability - without logs you cannot tell whether 1 or 2 has already been exploited.
Corrected rule set, in evaluation order:
- Outside to DMZ: HTTPS to the portal's specific address only. No RDP, no any-service.
- Remote administration: replace direct RDP with a VPN gateway requiring multi-factor authentication, then RDP from the VPN address pool to a named jump host only, restricted by source group.
- Inside to DMZ: explicit per-service rules - HTTPS to the portal, the backup protocol on its specific port from the file server's address only. Delete the temporary any-service rule.
- DMZ to inside: default deny, with no exceptions initiated from the DMZ.
- DMZ to outside: only the update sources the application genuinely needs, by destination and port.
- Explicit deny-any at the end of each zone pair, with logging on.
Enable logging on deny rules and on any rule permitting RDP, with alerts on RDP rule hits outside maintenance windows.
3. The backup now has no matching rule yet still completes in 9 hours instead of the expected 2. What is your hypothesis, and how would you establish the facts without guessing?
Read the worked answer
A job with no matching rule that still transfers data means traffic is taking a path the rule set does not describe. Two candidates dominate: the DMZ server and the file server share a Layer 2 segment or a route that bypasses the firewall, or a rule exists elsewhere - a second firewall, a virtual context, or a NAT rule matched before the security policy - that the audit did not cover. Do not accept 'no rule' as a conclusion until the flow is proven.
Establish facts in this order:
- Confirm the path. Run a traceroute and a capture on both endpoints and on the firewall's DMZ and inside interfaces, and identify which interfaces the flow actually crosses. If the firewall sees no packets, the bypass is confirmed.
- If the firewall is in the path, check session and rule hit counters for the flow, then look for a proxy, application inspection or an IDS/IPS profile applied to the matching rule - deep inspection of a 400 GB stream can easily account for the 7-hour difference.
- Check the transport itself. Nine hours for 400 GB is roughly 100 Mb/s sustained. Look for a 100 Mb/s port in the path, a duplex mismatch, a congested uplink, or TCP window and retransmission counters. If the flow crosses the IPsec or DMZ segment from the previous discussion, verify MSS clamping.
- Vendor out the finding. Names and version numbers matter - record devices, interfaces, counters, and timestamps.
Only then write the rule the flow needs: specific source, specific destination, one port, logging on, with an owner and an expiry date recorded in the rule description.