Tuesday, February 25, 2014

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...