Source NAT Requirement — Why Sessions Created but No Response

Quick Answer

The correct answer points to source NAT because the symptom pattern here is a classic giveaway: the session is created, meaning the security policy allowed the traffic and the firewall forwarded the packet, but no reply ever comes back. That split between a successful forward path and a missing return path is a strong signal that the problem is with addressing rather than policy. Without source NAT, the firewall preserves the internal host's private IP as the source address when it sends the packet toward the external server. That server has no route back to a private address across the public internet, so the reply never finds its way back to the firewall, and nothing shows up in the logs because nothing arrives. This is different from a policy problem, where the session would show a deny or drop before ever being created, and different from a routing issue on the firewall itself, which would usually prevent the session from forming at all. The habit worth building here is to treat 'session created, but no response seen' as a routing or NAT symptom first: whenever traffic is allowed and forwarded but silence follows, check whether the source address is even reachable by the far end before you start second-guessing the security policy.