Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

One-to-one NAT

VIEWS: 13 PAGES: 7

									One-to-one NAT

Printer Friendly Version [ PDF ]

WatchGuard Firebox System v5.0 introduced the ability for the Firebox to perform 1:1 NAT. This
functionality is useful for many situations when static port NATting isn't an option.


What is one-to-one NAT?

1-to-1 NAT is used to map one or more IP addresses in one range to another range of the same
size. Each IP in the first range maps to one and only one unique IP in the second range. When
ranges are are mapped, the ranges are related mathematically. For example, if network
192.168.1.x with a base of 1 translates to network 10.10.10.x with a base of 20 then 192.168.1.1
becomes 10.10.10.20, 192.168.1.2 becomes 10.10.10.21 and so on. Because of this static
mapping, the idea of data flow "direction" is much less important, and no "connection state"
information about the sessions needs to be stored on the Firebox. This is extendable from one NAT
to thousands of NATs.

With 1-to-1 NAT, all IP protocols are translated. Be aware that protocols that pass IP addresses in
the session layer may have trouble with one-to-one NAT (H.323, IPSec's AH, and FTP are good
examples).


Some cases where static-NAT would be useful

There are several reasons a site might choose to use 1-to-1 NAT. One common reason is to map
public IP address to internal servers without needing to renumber the internal servers (particularly
useful for managed service providers). It should be noted that doing this offers no additional
security, and service rules will still need to be applied to achieve a secured network. Some other
uses are:

        Custom applications where the client machine must appear to have a public IP address
        IPSec ESP connections (most common)
        PPTP connections
        Certian cases where mail servers must communicate through their MX record's IP address if
         it's not the main IP address of the Firebox


Important considerations before implementing one-to-one NAT

Note: The Firebox operates one-to-one NAT through Proxy-ARP, so it is important that the NATted
IP addresses do NOT match any of the aliases or interfaces on the Firebox. If you have one of the
Fireboxes interfaces configured for the IP that you wish to use for one-to-one NAT, the NAT will fail.

One-to-one NAT will not work with IPSec AH (IPSec ESP works fine), DCE-RPC, RTSP, or H.323.
Remember that the Firebox will still place rules on the packets entering one of the Firebox's
interfaces. One-to-one NAT is also not a shortcut across the normal firewalling rules configured with
the Policy Manager. The incoming (or outgoing) packet must still pass the allow/deny set before it is
put through the NAT on the Firebox.


Here is how a packet will normally traverse the Firebox with NAT enabled:

    1.   Packet is routed to the Firebox - directly or through proxy-ARP.

    2.   Does this packet match the Blocked Sites list? If so, block it.

    3.   Does this packet match the Blocked port list? If so, add the source IP to blocked sites and
         block it.
    4.   Does it pass the allow/deny rules configured in the Policy Manager and/or temporary rules
         created by H.323, FTP, DCE-RPC, Dynamic-NAT temporary rules, or Static-NAT temporary
         rules? If not, deny it and stop.

    5.   Does it match any network routes? If so, forward the packet to the next router.

    6.   Does it match a static-NAT rule? If so, NAT it and send out the appropriate interface.

    7.   Does is match a dynamic-NAT exceptions rule? If so, skip over to step 9.

    8.   Does it match a dynamic-NAT rule? If so, NAT it and send it out the appropriate interface.

    9.   Does it match a one-to-one NAT rule? If so, NAT it and send it out the appropriate
         interface.


Here is an implementation example that will help explain how to configure
one-to-one NAT.




We have a client (this could also be a server on the Optional to Trusted interface) with an IP
address of 192.168.1.15. This PC must `appear to' have a public IP address for some reason. These
reasons could be any of several mentioned above. Although the static-NAT on the Firebox can be
configured for any number of IP addresses, only one will be conifgured in this example. We will go
through the configuration on the Firebox to set up this static-NAT, and assume that the Firebox has
a fairly standard default configuration, with no one-to-one NAT configured yet.
1.   Open the current configuration with the Policy Manager.

2.   Click View.

3.   Make sure Advanced is checked.

4.   Click Setup => NAT.

5.   Click Advanced.
     The Advanced NAT setup window will appear


6.   Click the 1-to-1 NAT Setup tab.




7.   Click the Enable 1-to-1 NAT checkbox.

8.   Click Add.
     The 1-to-1 Mapping window will appear
    9.   Configure this window as follows:
         Interface: External (this is the interface that the NATted address will appear on)
         Number of hosts to NAT: 1 (this can be any number, in our case we only have one host we need to
         NAT)
         NAT base: 1.2.3.4 (this is the address that will appear on the interface specified in the Interface option
         Real base: 192.168.1.15 (this is the address that is the REAL address on the PC we are NATting)


The interface selection is the interface on which that the Firebox will proxy-ARP for the `NAT base'.
If this was Optional, the IP address `1.2.3.4' would be available on the Optional interface for clients
to access, and conversely, when the 192.168.1.15 PC's packets routed out via the Optional
interface, the one-to-one NAT would be applied.

    10. Click OK.
         The Advaced NAT settings box will return, with our configuration




    11. Click the Dynamic-NAT Exceptions tab.
         We must now configure 192.168.1.15 to be excepted from the dynamic-NAT rules. If the dynamic-NAT
         rule was still active on the 192.168.1.15 address, the one-to-one NAT would fail. There is more
         information on this and how the precedence on the Firebox for NAT works near the beginning of this
         document.
12. Click Add.
    The Add Exception window will appear




13. Configure the window as follows:
    From: 192.168.1.15 (this is the "real" IP address range that we are choosing to except from dynamic-
    NAT)
    To: external (this is the "NAT" address that we are trying to avoid NATting to)


14. Click OK.
    The Advanced NAT settings window will reappear
We have configured a Dynamic-NAT exception rule. This rule is similar to a Dynamic-NAT rule, and is discussed in
greater detail above.


    15. Click OK.

    16. Finally, we must make sure that the IP address we have chosen for the external side of this
        one-to-one NAT rule is not in use by any other interfaces, that it is not an external interface
        alias.

    17. Click Network => Configuration.

    18. Click the External tab.

    19. Click Aliases.

    20. Verify that the 1.2.3.4 address does not appear in this list.

    21. Click OK.

    22. Now configure any service rules that you may need for the desired connections to function
        properly.
         Note that any service rules that you configure must have the To: address configured as the destination
         IP address of the desired connection to the client. For example, if you wanted people on the Internet to
         be able to contact our 192.168.1.15 PC on TCP port 80 throgh an HTTP filter, the HTTP service would be
         configured as Incoming: Enabled and Allowed, From: Any - To: 1.2.3.4. Conversely, if you wanted the
         192.168.1.15 PC to be able to connect to the Internet with an HTTP filter, the service rules would be
         Outgoing: Enabled and Allowed, From: 192.168.1.15 - To: Any.


    23. Save this configuration to the Firebox. A Firebox reboot should not be necessary for
        modifying the NAT rules or the service rules.


Graphic representation
This is a diagram of how a TCP packet will traverse the network in the above configuration example.

TCP connection is attempted from 100.100.100.100 to 1.2.3.4, which has a NAT rule on the Firebox.

    1.   Packet is routed over the Internet from the client (100.100.100.100) to the Firebox's
         network.




    2.   The router ARPs for the 1.2.3.4 IP address.

    3.   Firebox responds with its external MAC address, because a one-to-one NAT rule has been
         established in the configuration file.

    4.   Router sends the packet to the Firebox.

    5.   Firebox examines the packet, it is allowed to pass through the policy rules.

    6.   NAT is applied to the packet and it is routed to the appropriate interface. It now looks like
         this:




    7.   The PC at 192.168.1.15 replies with a TCP SYN-ACK to the source IP address of the SYN
         packet. This packet looks like this:




    8.   Because the Firebox is the default gateway of this PC, the packet is routed to the Firebox.

    9.   The Firebox NATs the packet so the source IP address is 1.2.3.4. The packet now looks like
         this:




This TCP communication can continue in this manner indefinately.

								
To top