Tenant Logical System Cannot Reach the Internet After Source NAT
An SRX1500 runs a master logical system and ls-tenant-a. ge-0/0/1.0 is assigned to ls-tenant-a as 10.50.0.1/24 in zone trust. A logical tunnel connects the tenant to the master: lt-0/0/0.0 is 169.254.10.1/30 in ls-tenant-a zone transit, and lt-0/0/0.1 is 169.254.10.2/30 in master zone transit. The master's ge-0/0/0.0 is 198.51.100.2/30 in zone untrust. Tenant hosts use 0.0.0.0/0 via 169.254.10.2; the master has 10.50.0.0/24 via 169.254.10.1. Policies permit trust-to-transit in the tenant and transit-to-untrust in the master. An administrator configured a source NAT rule inside ls-tenant-a that translates 10.50.0.0/24 to interface. Host 10.50.0.10 can ping 169.254.10.2 but cannot reach 8.8.8.8. show security flow session logical-system ls-tenant-a shows outbound sessions to 8.8.8.8, but show security nat source summary logical-system ls-tenant-a shows zero translations. The master shows no source NAT rule.
1. Why can the tenant ping the logical tunnel peer but not reach the Internet? Identify where source NAT must be configured and why the existing rule is not translating.
Read the worked answer
The ping to 169.254.10.2 succeeds because it is tenant-local traffic on the lt link. It does not need to leave the tenant routing instance, does not traverse the master's untrust interface, and does not require source NAT. The Internet-bound packet is different: the tenant routes it out lt-0/0/0.0 to the master, the master accepts it in zone transit, the transit-to-untrust policy permits it, and the master attempts to egress ge-0/0/0.0 toward 8.8.8.8.
Source NAT is applied in the context of the egress interface and its logical system. A source NAT rule configured inside ls-tenant-a can only be evaluated for traffic whose egress interface belongs to ls-tenant-a. The actual egress interface here is the master's ge-0/0/0.0, so the tenant's NAT rule is never consulted. That is why the tenant session exists but the tenant NAT counters are zero. The packet leaves the master with source 10.50.0.10, which is a private address; the return path fails. The rule must be configured in the master logical system, matching the tenant source prefix and translating to the untrust interface or a public pool.
2. After the rule is moved to the master, how would you verify NAT and the return path? List the specific observations that would distinguish a NAT match failure from a routing or policy failure.
Read the worked answer
Start on the master with show security nat source summary and show security nat source rule all to confirm the rule exists in the master, references the correct egress interface or pool, and increments its translation count when 10.50.0.10 sends traffic. Then use show security flow session on the master for the 10.50.0.10-to-8.8.8.8 flow. A working flow should show a session in the master with the translated source address in extensive output; if the session shows the original private source even though the rule exists, the rule match or egress-interface association is wrong.
Separate NAT from routing and policy by checking the session at each stage. If no master session exists at all, the packet is being dropped before egress, so check the transit-to-untrust policy and zone assignment. If a master session exists with the correct translation but no replies, check show route 8.8.8.8, the default route, and the upstream return path. Also confirm the master has a route for 10.50.0.0/24 via the lt interface, because return traffic must be delivered back into the tenant. The tenant's own NAT counters should stay at zero after the move; that is expected.