Policy-based NATing on ScreenOS

Source NATing

I recently had to deploy a firewall for a home user where the VPN address space was limited, and it would be best to not re-IP the LAN devices as only specific destinations would be accessed through the VPN. To accomplish this, I employed some simple static routing and source NATing.

When sending traffic from the LAN through the VPN, because we're using the same addressing space (for this example 10.10.0.0/16) source NATing allows us to have a neutral address for both the source and destination.

If you would like to have more than one host connecting with unique IP addresses, it's best to utilize a DIP pool to use with your NATing; this acts much like a DHCP pool. You can additionally enable PAT (Port Address Translation) which supports up to 64,500 hosts simultaneously. However, a DIP pool is best used (with PAT disabled) when the source port number must remain fixed. When done in this fashion, the SSG will issue one address for the same host for all of it's sessions. Whereas with PAT enabled, each session might receive a unique source address.

If you do not specify a DIP pool, the SSG will translate the source address to the egress (outgoing) interface. When you do this, PAT is automatically enabled. I find this way much easier for our purpose.

So first thing's first, lets define our hosts; because we're connecting from a handful of possible devices who are utilizing DHCP, we're going to just define the entire subnet:

set address "Trust" "192.168.1.0/24" 192.168.1.0 255.255.255.0
set address "DMZ" "10.10.0.0/16" 10.10.0.0 255.255.0.0

The DMZ address here is our remote network.

Now for the routing:

set route 10.10.0.0/16 interface tunnel.1

So anything destined for 10.10.0.0/16 will be routed through the tunnel interface; which just so happens to have an address in that scheme.

Now for the policy and NAT:

set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src permit log

Any traffic from our local subnet of 192.168.1.0/24 destined for 10.10.0.0/16 will be routed through the tunnel interface after being NATed to the egress interface's IP address; our tunnel interface, which as stated earlier holds an IP in the 10.10.0.0/16 scheme!

For those of you who wish to use a DIP pool, I've got you covered!

set interface ethernet0/1 dip 1 10.10.1.1 10.10.1.254 fix-port
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src dip-id 1 permit log 

For this to work, because the 10.10.0.0/16 network lives on both ends of the tunnel, a route on the head will have to be set to route anything destined for the 10.10.1.0/24 range through the tunnel to our LAN.

The fix-port option in the DIP denotes that PAT will not be used.; remove this option to enable PAT.


To be continued with destination NATs, MIPs and VIPs...

Creating a VIP in ScreenOS

Port-forwarding in the Juniper world is done by creating MIPs, VIPs and DIPs. A virtual IP (VIP) address maps traffic received at one IP address to another address based on the destination port number in the TCP or UDP segment header. Mapped IP (MIP) is a direct one-to-one mapping of one IP address to another(public ip to private ip ) that means hiding some resources (server) from the public. A dynamic IP (DIP) address pool is a range of IP addresses from which the device can dynamically take addresses to use when performing NAT on the source IP address of outgoing or incoming IP packets.

You can link three types of interfaces to Dynamic IP (DIP) pools: physical interfaces and sub-interfaces for network and VPN traffic, and tunnel interfaces for VPN tunnels only

The most common use for a VIP is to map several DMZ intranet servers to a single public ip address on very small firewalls.

Setup

NOTE: a VIP must be created in the same network as the interface. If you want to forward from another subnet, you need to use NAT-DST

You can create a VIP under two conditions:
1. Your client's Public IP address is on the same network as the Firewall's Untrust interface IP address
2. Your client's Public IP address is the same IP address as the Firewall's Untrust interface IP address

You can assign the IP for the VIP in three ways.
1. Interface IP
2. Zone IP (Untrust)
3. Statically assign it

The address you assign your VIP must be on the same subnet as your Untrust (or the same address entirely), this only comes in to play when using option 3

interface-ip is your best bet for a dynamic address but will only work on ver 6.1 and up
untrust-ip is your next best alternative for use with a dynamic address, but if you have multiple interfaces in the untrust zone, it will choose the default (usually e0/0)
static is if you have the privledge of having a static IP adddress on the interface

For every port you wish you forward, you have to create a unqiue VIP
For example, if you want IMAP and SMTP traffic forwarded to your server at 192.168.1.101 you'll need to set up two VIPs on your outside interface:

set int e0/0 vip interface-ip 143 "IMAP" 192.168.1.101
set int e0/0 vip interface-ip 25 "SMTP" 192.168.1.101

Switcharoo

Sometimes you will need to forward unconventional ports; usually it's either to hide which ports you have open, or simply to accommodate software.
To do this you will need to explicitly define the service.

Say I want to use port 15011 for my BitTorrent traffic because the standard 69xx ports are being blocked; well Juniper doesn't know what operates on port 15011 because it's a non-standard port, therefore I'll have to define it. Because I know BitTorrent operates on 6881-6999, I can narrow down what traffic is forwarded.

set service "BitTorrent_15011" protocol tcp src-port 6881-6999 dst-port 15011-15011

Execution

Now we'll be able to apply this service to a policy (ACL on Cisco appliances)

set policy id 100 from "Untrust" to "Trust" "Any" "VIP(ethernet0/0)" "HTTP" permit log
set policy id 100
set service "BitTorrent_15011"

This will allow all traffic inbound to port 6881-6999 to be forwarded to my 192.168.1.101 client on port 15011.

Mind you, whatever your destination client is, has to be configured to be listening on the port the traffic is being forwarded to. In this case 15011.