Tag Archives: NAT

JNCIS-SEC, Security

JNCIS-SEC – SRX Static NAT Configuration

2 Comments

I already went into source and destination NAT in the last few posts. The last one I wanted to lab up is Static NAT, which creates a one-to-one mapping between two addresses. The translation is bidirectional and ports are not translated. On the downside, it does require you to sacrifice one public IP per internal server which is not always the most cost-efficient method.

Here’s what I’ll be working on:

SRX NAT topology

The following Static NAT entries will be configured:

  • Server 10.0.100.10 will be translated to 1.1.1.10
  • Server 10.0.100.11 will be translated to 1.1.1.11

Using the Global Address Book

Instead of using regular IP prefixes as matching conditions, I will be using address book entries in the NAT config. Referring to the same names in both security policy and NAT makes interpreting and troubleshooting the config much more straightforward.

First, navigate over to the global address book under Security, and enter addresses as you would under the zones. I am creating objects for both the public and private addresses: 

[edit security address-book global]
root@NP-vSRX-01# show
address Host-Private-10.0.100.10 10.0.100.10/32;
address Host-Private-10.0.100.11 10.0.100.11/32;
address Host-Public-1.1.1.10 1.1.1.10/32;
address Host-Public-1.1.1.11 1.1.1.11/32;

Caution, when you start adding entries to the global address book, the SRX will start spawning this error when trying a commit: 

[edit security zones security-zone untrust]
root@NP-vSRX-01# show
##
## Warning: Zone specific address books are not allowed when there are global address books defined
##

From the looks of it, you will need to move all your zone address books over to the global one, so make sure you start off right on a new SRX. Worst case, you can still match on regular IP prefixes for NAT.

Next will be to define a ruleset, and create some rules. One thing to keep in mind is that you configure the NAT rule to match on the destination address to perform the NAT. Implicitly, the SRX will then create a reverse source-NAT mapping. Just imagine the traffic entering your network, and to what address it should be translated, and the SRX will take care of the reverse traffic for you.

Here is the configuration for the first host, referencing the object name by using destination-address-name: 

[edit security nat static]
root@NP-vSRX-01# show
rule-set Static-From-Untrust {
    from zone untrust;
    rule NAT-DMZ-10 {
        match {
            destination-address-name Host-Public-1.1.1.10;
        }
        then {
            static-nat {
                prefix-name {
                    Host-Private-10.0.100.10;
                }
            }
        }
    }
}

Copy paste for the second host:

rule NAT-DMZ-11 {
    match {
        destination-address-name Host-Public-1.1.1.11;
    }
    then {
        static-nat {
            prefix-name {
                Host-Private-10.0.100.11;
            }
        }
    }
}

Verification

The most useful command for Static NAT verification is show security nat static rule, which shows you both a config overview and a hit count. 

root@NP-vSRX-01> show security nat static rule all
Total static-nat rules: 2
Total referenced IPv4/IPv6 ip-prefixes: 4/0

Static NAT rule: NAT-DMZ-10           Rule-set: Static-From-Untrust
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : untrust
  Destination addresses      : Host-Public-1.1.1.10
  Host addresses             : Host-Private-10.0.100.10
  Netmask                    : 32
  Host routing-instance      : N/A
  Translation hits           : 40
    Successful sessions      : 34
    Failed sessions          : 6
  Number of sessions         : 0

Static NAT rule: NAT-DMZ-11           Rule-set: Static-From-Untrust
  Rule-Id                    : 2
  Rule position              : 2
  From zone                  : untrust
  Destination addresses      : Host-Public-1.1.1.11
  Host addresses             : Host-Private-10.0.100.11
  Netmask                    : 32
  Host routing-instance      : N/A
  Translation hits           : 112
    Successful sessions      : 112
    Failed sessions          : 0
  Number of sessions         : 0

To emphasize that no PAT is performed, here is an output of the session table. We are using port 50973 on both ends of the firewall. 

Session ID: 15148, Policy name: FW-PermitWeb/7, Timeout: 4, Valid
  In: 10.0.100.11/50973 --> 91.189.92.200/80;tcp, If: ge-0/0/1.0, Pkts: 26, Bytes: 5673
  Out: 91.189.92.200/80 --> 1.1.1.11/50973;tcp, If: ge-0/0/0.0, Pkts: 25, Bytes: 5863
JNCIS-SEC, Security

JNCIS-SEC – Port forwarding on the SRX

Leave a comment

A common technique to obscure services from network probing is to host them on ports outside of the well-known ports range. This might help as a first defense, but in reality the ports are still there for anyone who steps out of the defaults. It also makes life harder for other firewall engineers 🙂 On the other hand, if your ISP is blocking services hosted in the well-known range, it might be your only option.

As in all the NAT examples, here is the topology:

SRX NAT topology

We are hosting an SFTP server, but are fed up with all the bruteforce attacks, so decide to host it on a different port. Traffic coming from the untrust zone, destined for 1.1.1.11 and arriving at TCP port 2222, will be translated to port 22 on the inside.

First, we define the real, internal port at the DNAT pool, together with the internal IP.

[edit security nat destination]
root@NP-vSRX-01# show pool DNAT-Host100-11
address 10.0.100.11/32 port 22;

Then, we go to our rule set, which defined the traffic direction (from untrust) and enter the address and port on which it should be listening, plus the pool to translate to: 

[edit security nat destination rule-set DNAT-From-Untrust]
root@NP-vSRX-01# show
from zone untrust;
rule DNAT-Host100-11 {
    match {
        destination-address 1.1.1.11/32;
        destination-port {
            2222;
        }
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-11;
            }
        }
    }
}

That’s it. After doing a telnet to port 2222, we see the following flow in the table: 

Session ID: 167059, Policy name: FW-SSH-Server/6, Timeout: 1778, Valid
  In: 10.6.60.68/62340 --> 1.1.1.11/2222;tcp, If: ge-0/0/0.0, Pkts: 3, Bytes: 132
  Out: 10.0.100.11/22 --> 10.6.60.68/62340;tcp, If: ge-0/0/1.0, Pkts: 2, Bytes: 126

Port forwarding with a dynamic IP

If you are running a dynamic IP address, it won’t be possible to define one IP as a match condition. Unless your ISP is always handing out addresses in one specific range, the only option is to define the destination-address as 0.0.0.0/0

All config stays the same, but the DNAT rule looks like this: 

[edit security nat destination rule-set DNAT-From-Untrust rule DNAT-Host100-11]
root@NP-vSRX-01# show
match {
    destination-address 0.0.0.0/0;
    destination-port {
        2222;
    }
}
then {
    destination-nat {
        pool {
            DNAT-Host100-11;
        }
    }
}
JNCIS-SEC, Security

JNCIS-SEC Lab – Destination NAT

2 Comments

In this lab, we will look at configuring the SRX to translate the destination field for incoming traffic, which is widely used for public servers in a DMZ.

As with all the NAT examples, I’ll be using the following topology:

SRX NAT topology

These are the requirements for the translations:

  • Only applies to traffic coming from the internet (untrust zone)
  • Destination 1.1.1.10/32 will be translated to DMZ IP 10.0.100.10/32
  • Destination 1.1.1.11/32 will be translated to DMZ IP 10.0.100.11/32

First, I will configure security policies for the following services:

  • Server 10.0.100.10 is hosting a Telnet server
  • Server 10.0.100.11 is an SSH/SFTP server

Because DNAT happens before policy lookup, we always refer to the address as it will be after translation.

[edit security policies from-zone untrust to-zone dmz]
root@NP-vSRX-01# show
policy FW-Telnet-Server {
    match {
        source-address any;
        destination-address Host-10.0.100.10-32;
        application junos-telnet;
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}
policy FW-SSH-Server {
    match {
        source-address any;
        destination-address Host-10.0.100.11-32;
        application junos-ssh;
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}

As this is a fresh config, we will first define a rule-set that specifies the traffic direction. Destination NAT does not give you the option to specify the to-zone, just the source zone.

[edit security nat destination]
root@NP-vSRX-01# show
rule-set DNAT-From-Untrust {
    from zone untrust;
}

Now, let’s add the two pools:

[edit security nat destination]
root@NP-vSRX-01# show
pool DNAT-Host100-11 {
    address 10.0.100.11/32;
}
pool DNAT-Host100-10 {
    address 10.0.100.10/32;
}

And here are the NAT rules themselves: 

[edit security nat destination rule-set DNAT-From-Untrust]
rule DNAT-Host100-10 {
    match {
        destination-address 1.1.1.10/32;
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-10;
            }
        }
    }
}

rule DNAT-Host100-11 {
    match {
        destination-address 1.1.1.11/32;
    }
    then {
        destination-nat {
            pool {
                DNAT-Host100-11;
            }
        }
    }
}

Because the upstream router is in the same segment as our firewall, we will also need to add ProxyARP to the global NAT config.

[edit security nat]
root@NP-vSRX-01# set proxy-arp interface ge-0/0/0.0 address 1.1.1.10/32 to 1.1.1.11/32

Verification

After starting a telnet and SSH session from my PC, this is the session table: 

Session ID: 166748, Policy name: FW-SSH-Server/6, Timeout: 1792, Valid
  In: 10.6.66.68/59016 --> 1.1.1.11/22;tcp, If: ge-0/0/0.0, Pkts: 3, Bytes: 132
  Out: 10.0.100.11/22 --> 10.6.66.68/59016;tcp, If: ge-0/0/1.0, Pkts: 2, Bytes: 126

Session ID: 166759, Policy name: FW-Telnet-Server/5, Timeout: 1798, Valid
  In: 10.6.66.68/60731 --> 1.1.1.10/23;tcp, If: ge-0/0/0.0, Pkts: 11, Bytes: 510
  Out: 10.0.100.10/23 --> 10.6.66.68/60731;tcp, If: ge-0/0/1.0, Pkts: 14, Bytes: 652

root@NP-vSRX-01> show security nat destination summary
Total pools: 2
Pool name            Address                           Routing        Port  Total
                     Range                             Instance             Address
DNAT-Host100-11      10.0.100.11    - 10.0.100.11                     0     1
DNAT-Host100-10      10.0.100.10    - 10.0.100.10                     0     1

Total rules: 2
Rule name            Rule set       From                               Action
DNAT-Host100-11      DNAT-From-Untrust untrust                         DNAT-Host100-11
DNAT-Host100-10      DNAT-From-Untrust untrust                         DNAT-Host100-10

root@NP-vSRX-01> show security nat destination pool all
Total destination-nat pools: 2

Pool name       : DNAT-Host100-11
Pool id         : 3
Total address   : 1
Translation hits: 1
Address range                        Port
    10.0.100.11 - 10.0.100.11           0

Pool name       : DNAT-Host100-10
Pool id         : 4
Total address   : 1
Translation hits: 8
Address range                        Port
    10.0.100.10 - 10.0.100.10           0
JNCIS-SEC, Security

JNCIS-SEC Lab – Pool-based Source NAT

Leave a comment

In the previous article, I configured the SRX to translate outgoing traffic to the external interface IP. In this article, we will look at a second way of configuring Source NAT, using a NAT address pool.

Again, I will be using the same topology:

SRX NAT topology

For the Source NAT with address pool, this is the requirement:

  • Traffic from the hosts in range 10.0.200.0/24
  • Destined to the untrust zone (the internet)
  • will be SNAT’ed to a pool with one IP address, 1.1.1.2/32

The firewall policies from the previous article, which allow basic web access, are still in place: 

root@NP-vSRX-01# show security policies from-zone trust to-zone untrust
policy FW-PermitWeb {
    match {
        source-address Net-10.0.200.0-24;
        destination-address any;
        application [ junos-http junos-https junos-dns-udp ];
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}

First, configure a rule-set that defines the traffic direction:

[edit security nat source]
root@NP-vSRX-01# show
rule-set NAT-Trust-to-Internet {
    from zone trust;
    to zone untrust;
}

Then, create the address pool: 

[edit security nat source]
root@NP-vSRX-01# set pool SNAT-Pool-Trust-to-Internet address 1.1.1.2/32

Next, configure the NAT rule based on the requirements: 

[edit security nat source rule-set NAT-Trust-to-Internet rule NAT-Source-VLAN200]
root@NP-vSRX-01# show
match {
    source-address 10.0.200.0/24;
}
then {
    source-nat {
        pool {
            SNAT-Pool-Trust-to-Internet;
        }
    }
}

After a commit, the SRX is correctly translating the traffic to 1.1.1.2 (Out > In traffic):

root@NP-vSRX-01> show security flow session source-prefix 10.0.200.10/32
Session ID: 38803, Policy name: FW-PermitWeb/4, Timeout: 42, Valid
  In: 10.0.200.10/23772 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 63
  Out: 8.8.8.8/53 --> 1.1.1.2/15049;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

### omitted for brevity ###

Session ID: 38809, Policy name: FW-PermitWeb/4, Timeout: 42, Valid
  In: 10.0.200.10/15346 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/13144;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 7

Unfortunately, the machine does not have internet access yet. As we are translating to an address other than our interface IP, the upstream router does not have an ARP entry for it. To solve this problem, we could add a static route on the “ISP” router, or configure Proxy-ARP on the SRX. In the real world, getting an ISP to make changes would take days so let’s do Proxy ARP.

First, find the interface which has our public IP:

[edit security nat]
root@NP-vSRX-01# run show interfaces terse | match 1.1.1.1
ge-0/0/0.0              up    up   inet     1.1.1.1/28

Then, configure the proxy-arp as a global NAT command: 

[edit security nat]
root@NP-vSRX-01# set proxy-arp interface ge-0/0/0.0 address 1.1.1.2

Let’s see if we now have more sessions from the clients:

root@NP-vSRX-01# run show security flow session source-prefix 10.0.200.0/24
Session ID: 38967, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/54278 --> 54.149.61.73/443;tcp, If: ge-0/0/2.0, Pkts: 10, Bytes: 1265
  Out: 54.149.61.73/443 --> 1.1.1.2/4408;tcp, If: ge-0/0/0.0, Pkts: 8, Bytes: 3905

Session ID: 38971, Policy name: FW-PermitWeb/4, Timeout: 292, Valid
  In: 10.0.200.10/52289 --> 91.189.89.88/80;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1145
  Out: 91.189.89.88/80 --> 1.1.1.2/29288;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 952

Session ID: 38975, Policy name: FW-PermitWeb/4, Timeout: 298, Valid
  In: 10.0.200.10/42145 --> 93.184.220.29/80;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1250
  Out: 93.184.220.29/80 --> 1.1.1.2/24688;tcp, If: ge-0/0/0.0, Pkts: 5, Bytes: 1844

Session ID: 38986, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/39442 --> 68.232.34.191/443;tcp, If: ge-0/0/2.0, Pkts: 9, Bytes: 1144
  Out: 68.232.34.191/443 --> 1.1.1.2/5689;tcp, If: ge-0/0/0.0, Pkts: 16, Bytes: 14208

### omitted for brevity ###

Session ID: 39167, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/42964 --> 37.252.170.5/443;tcp, If: ge-0/0/2.0, Pkts: 7, Bytes: 1577
  Out: 37.252.170.5/443 --> 1.1.1.2/6620;tcp, If: ge-0/0/0.0, Pkts: 6, Bytes: 1515

Session ID: 39169, Policy name: FW-PermitWeb/4, Timeout: 1792, Valid
  In: 10.0.200.10/42966 --> 37.252.170.5/443;tcp, If: ge-0/0/2.0, Pkts: 8, Bytes: 1641
  Out: 37.252.170.5/443 --> 1.1.1.2/25579;tcp, If: ge-0/0/0.0, Pkts: 7, Bytes: 1636

Session ID: 39172, Policy name: FW-PermitWeb/4, Timeout: 1794, Valid
  In: 10.0.200.10/45036 --> 37.252.170.182/443;tcp, If: ge-0/0/2.0, Pkts: 11, Bytes: 3599
  Out: 37.252.170.182/443 --> 1.1.1.2/32160;tcp, If: ge-0/0/0.0, Pkts: 10, Bytes: 6143
Total sessions: 55

Now that it’s working and we have HTTP and HTTPS sessions established, here is the full configuration again: 

[edit security nat]
root@NP-vSRX-01# show
source {
    pool SNAT-Pool-Trust-to-Internet {
        address {
            1.1.1.2/32;
        }
    }
    rule-set NAT-Trust-to-Internet {
        from zone trust;
        to zone untrust;
        rule NAT-Source-VLAN200 {
            match {
                source-address 10.0.200.0/24;
            }
            then {
                source-nat {
                    pool {
                        SNAT-Pool-Trust-to-Internet;
                    }
                }
            }
        }
    }
}
proxy-arp {
    interface ge-0/0/0.0 {
        address {
            1.1.1.2/32;
        }
    }
}

Translating to a range, with PAT

When using Port Address Translation, using one IP address gives us a theoretical 65.536 available ports (less are used for outbound connections), which means an equal amount of concurrent sessions. When we are nearing the limit with one IP address, we can add more addresses to the pool.

Suppose that we want to add 1.1.1.3/32 to the mix, we have two options. We can change the mask to /31:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/31;
}

Or, we can specify a from-to range:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/32 to 1.1.1.3/32;
}

After a commit, the flow table shows it’s translating to both 1.1.1.2 and 1.1.1.3 for one of my lab machines:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# run show security flow session
Session ID: 123095, Policy name: FW-PermitWeb/4, Timeout: 52, Valid
  In: 10.0.200.11/10224 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 3, Bytes: 189
  Out: 8.8.8.8/53 --> 1.1.1.3/15041;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

  ### omitted ### 
  
Session ID: 123104, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.11/24055 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/26041;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 179

Session ID: 123105, Policy name: FW-PermitWeb/4, Timeout: 58, Valid
  In: 10.0.200.11/57407 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 65
  Out: 8.8.8.8/53 --> 1.1.1.3/2018;udp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0

Session ID: 123106, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.11/46570 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 67
  Out: 8.8.8.8/53 --> 1.1.1.2/11394;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 123

Session ID: 123107, Policy name: FW-PermitWeb/4, Timeout: 18, Valid
  In: 10.0.200.11/33438 --> 91.189.92.201/80;tcp, If: ge-0/0/2.0, Pkts: 2, Bytes: 120
  Out: 91.189.92.201/80 --> 1.1.1.3/17036;tcp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 9

Unfortunately, this doesn’t always work flawlessly. We can instruct JunOS to always NAT one particular client to the same external IP by adding the global source-NAT command address-persistent

[edit security nat source]
root@NP-vSRX-01# set address-persistent

[edit security nat source]
root@NP-vSRX-01# commit
commit complete

Disabling Port Address Translation

By default, the SRX will translate the outgoing port to a random number. We can disable this by adding port no-translation to the pool configuration.

Assume the following configuration:

  • The previous SNAT pool of 1.1.1.2/31 will remain as configured but PAT will be disabled
  • If the SRX runs out of available ports, we will PAT to the interface IP. This is referred to as an overflow pool.

SourceNAT configuration:

[edit security nat source pool SNAT-Pool-Trust-to-Internet]
root@NP-vSRX-01# show
address {
    1.1.1.2/32 to 1.1.1.3/32;
}
port {
    no-translation;
}
overflow-pool interface;

As shown below, the outgoing port stays the same on both the ingress and egress session. 

oot@NP-vSRX-01# run show security flow session
Session ID: 164827, Policy name: FW-PermitWeb/4, Timeout: 290, Valid
  In: 10.0.200.10/48125 --> 91.189.91.23/80;tcp, If: ge-0/0/2.0, Pkts: 25, Bytes: 5621
  Out: 91.189.91.23/80 --> 1.1.1.2/48125;tcp, If: ge-0/0/0.0, Pkts: 24, Bytes: 5768[edit]


To conclude, here are some show commands that will help during config and troubleshooting


root@NP-vSRX-01> show security nat source summary
Total port number usage for port translation pool: 64512
Maximum port number for port translation pool: 33554432
Total pools: 1
Pool                 Address                  Routing              PAT  Total
Name                 Range                    Instance                  Address
SNAT-Pool-Trust-to-Internet 1.1.1.2-1.1.1.2   default              yes  1

Total rules: 1
Rule name          Rule set       From              To                   Action
NAT-Source-VLAN200 NAT-Trust-to-Internet trust      untrust              SNAT-Pool-Trust-to-Internet



root@NP-vSRX-01> show security nat source pool SNAT-Pool-Trust-to-Internet

Pool name          : SNAT-Pool-Trust-to-Internet
Pool id            : 4
Routing instance   : default
Host address base  : 0.0.0.0
Port               : [1024, 63487]
Twin port          : [63488, 65535]
Port overloading   : 1
Address assignment : no-paired
Total addresses    : 1
Translation hits   : 275
Address range                        Single Ports   Twin Ports
            1.1.1.2 - 1.1.1.2            1              0



root@NP-vSRX-01> show security nat source rule all
Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 1/0

source NAT rule: NAT-Source-VLAN200   Rule-set: NAT-Trust-to-Internet
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : trust
  To zone                    : untrust
  Match
    Source addresses         : 10.0.200.0      - 10.0.200.255
  Action                        : SNAT-Pool-Trust-to-Internet
    Persistent NAT type         : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout          : 0
    Max session number          : 0
  Translation hits           : 275
    Successful sessions      : 275
    Failed sessions          : 0
  Number of sessions         : 1
JNCIS-SEC, Security

JNCIS-SEC Lab – Interface NAT on the SRX

1 Comment

In this NAT configuration example I will be configuring Interface Network Adress Translation on the Juniper SRX, which will translate the source address of the original packets to the external interface addresss of the SRX.

This is the topology I will be using for all NAT configurations.

SRX NAT topology

These are the requirements for the configuration:

  • Traffic from the hosts in range 10.0.200.0/24
  • Destined to the untrust zone (the internet)
  • will be SNAT’ed to external interface IP of 1.1.1.1/32

First, I will configure an address book object for the network range.

[edit security zones security-zone trust]
root@NP-vSRX-01# set address-book address Net-10.0.200.0-24 10.0.200.0/24

And configure a security policy that allows http, https and dns-udp to the internet (any).

[edit security policies from-zone trust to-zone untrust policy FW-PermitWeb]
root@NP-vSRX-01# show
match {
    source-address Net-10.0.200.0-24;
    destination-address any;
    application [ junos-http junos-https junos-dns-udp ];
}
then {
    permit;
    log {
        session-close;
    }
}

To define the source NAT, I will first create a rule set that is specific for this zone pair.

Note – Rule-sets are where you will group different NAT rules based on traffic direction. You can match on interface, zone and routing-instance, as displayed below. When two rule-sets match for a particular traffic flow, the most specific one will be preferred, with interface being the most specific, then zones and finally routing-instances. 

[edit security nat source rule-set NAT-Trust-to-Internet]
root@NP-vSRX-01# set from ?
Possible completions:
+ interface            Source interface list
+ routing-instance     Source routing instance list
+ zone                 Source zone list

The rule-set for this zone pair: 

[edit security nat source]
root@NP-vSRX-01# show
rule-set NAT-Trust-to-Internet {
    from zone trust;
    to zone untrust;
}

And here is the NAT rule I have defined: 

[edit security nat source rule-set NAT-Trust-to-Internet]
root@NP-vSRX-01# show rule NAT-Source-VLAN200
match {
    source-address 10.0.200.0/24;
}
then {
    source-nat {
        interface;
    }
}

I could have also defined to match on 0.0.0.0/0 as the destination address, but that would just have been one more line of code.

Verifiying the translations: 

root@NP-vSRX-01> show security flow session source-prefix 10.0.200.0/24
Session ID: 17713, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.10/49751 --> 8.8.8.8/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 55
  Out: 8.8.8.8/53 --> 1.1.1.1/29242;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 71

Session ID: 17714, Policy name: FW-PermitWeb/4, Timeout: 2, Valid
  In: 10.0.200.10/49751 --> 8.8.4.4/53;udp, If: ge-0/0/2.0, Pkts: 1, Bytes: 55
  Out: 8.8.4.4/53 --> 1.1.1.1/13555;udp, If: ge-0/0/0.0, Pkts: 1, Bytes: 71
Total sessions: 2

We see an internal traffic flow from 10.0.200.10 going to 8.8.8.8 and 8.8.4.4 (IN). The return traffic (OUT) is being sent to a translated port on 1.1.1.1, the interface IP.
This means that the NAT is working as required.

For a brief summary of the NAT configuration, enter the following: 

root@NP-vSRX-01> show security nat source summary
Total port number usage for port translation pool: 0
Maximum port number for port translation pool: 33554432
Total pools: 0

Total rules: 1
Rule name          Rule set       From              To                   Action
NAT-Source-VLAN200 NAT-Trust-to-Internet trust      untrust              interface

And to view even more detail and some statistics about the rule: 

root@NP-vSRX-01> show security nat source rule NAT-Source-VLAN200

source NAT rule: NAT-Source-VLAN200   Rule-set: NAT-Trust-to-Internet
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : trust
  To zone                    : untrust
  Match
    Source addresses         : 10.0.200.0      - 10.0.200.255
  Action                        : interface
    Persistent NAT type         : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout          : 0
    Max session number          : 0
  Translation hits           : 604
    Successful sessions      : 604
    Failed sessions          : 0
  Number of sessions         : 0