1

I have inherited a network using a mix of SSG140s, 350M and 550M. Each of them is configured with a Trust, Untrust and VPN VR with multiple custom zones on each (we don't use the default zones).

[Zone: ISP Link]--(Untrust-VR)--(Trust-VR)--[Zone: Routed: Internal A]
                                          \
                                           -[Zone: NAT: Internal B]

I am struggling to understand the difference functional difference between how some of the zone are configured. We have two flavours:

  • Zones with Interface Type Route and policy based NAT applied.
    • The policy is configured to use the egress IP (no DIP)
  • Zones with Interface Type NAT, which just standard policies applied.

With an Interface in a Zone attached to the Trust-VR set to NAT, I can see from the logs that, NAT is not applied on traffic going to other Zones attached to the same Trust-VR.

As background I specifically ask because we had an issue with RTMP (TCP media streaming) over a zone configured with Policy based nat. It looked like it should work, the traffic logs shows the NAT being translated correctly but the TCP handshake never completed and no packets came back. I moved the source of the stream to a Zone with is configured with a NAT interface and it worked, the translation looked the same from the logs. This issue was specifically seen on an ssg140.

To sum up:

  • What is the difference between Policy NAT with no DIP and Interface based NAT?
  • Can I configure all Zones/Interfaces connected to the Trust-VR as NAT and not lose any functionality?
2
+100

What is the difference between Policy NAT with no DIP and Interface based NAT?

Interface-based NAT only works from the Trust zone to the Untrust zone (as in the default zones). Traffic between other zones will always be routed. The exception to all this (as you have discovered) is when the destination zone is in the Untrust VR, in which case, all traffic will be source NATted.

This is a hang-over from back in the Netscreen days, where there were no custom zones and most boxes had <=3 usable interfaces. They were automatically placed into Zones (these were actually silk-screened above the ports).

Policy-based source-NAT on the other hand will be applied whenever traffic matches the policy, regardless of zone/VR.

If you configure both (e.g. set the interface to NAT mode, and then configure a policy-based NAT) then the policy NAT will override the Interface NAT for that traffic.

Can I configure all Zones/Interfaces connected to the Trust-VR as NAT and not lose any functionality?

Yes, this should work fine - as above, all this traffic will be routed unless use a Trust or Untrust zone. If there are any NAT requirements, you can configure policy-based to override specific cases.

References: Juniper KB6725 - [ScreenOS] Configuration example using interface-based NAT:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB6725&pmv=print&actp=search&searchid=1236690693051&type=currentpaging

  • Thats for that, I had got a lot of that but not the historical reason for the behaviour. Is there any reason you can think of why a TCP stream may be treated differently under either NAT type? – Acyclic Tau Feb 9 '16 at 12:01
  • No, unless it matches a policy which is overriding the default behaviour. What are you seeing? – Benjamin Dale Feb 10 '16 at 12:56
  • I am seeing what looks to be exactly the same translation from the traffic logs, source only to external IP of the FW in both instances, but on the Policy NATed interface I see no connection made. All I did was move the streaming source from one zone to the other on the switch and magically the stream worked. I have been unable to retest as we have a live stream coming up and I don't want to break it, but next week I will be testing some more. – Acyclic Tau Feb 10 '16 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.