Technical Tip: VIP range for SNAT and static 1-to-1 mapping

[nsubramanian]

Description
This article shows an example of VIP ranges used to perform Source NAT (SNAT) with a static 1-to-1 mapping from internal to external IP addresses.
This is similar to using IPpool but with the advantage of having predictable and static 1-to-1 mapping.
The use of Virtual IP addresses is usually done to map external (public) to internal (private) IP addresses for Destination NAT (DNAT).

For more information about VIP, please see the  https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/657500

Solution

Associate each internal IP address to one external IP address for the Source NAT (SNAT) translation.

From the above diagram, that would mean:

CLI configuration of the Fortigate (only the relevant parts are displayed):

# config firewall vip
    edit "Static_NAT_1to1"
        set extip 192.168.37.4-192.168.37.8
        set extintf "port1"
        set mappedip 10.10.10.42-10.10.10.46
    next
end

# config firewall policy
    edit 1
        set srcintf "port2"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
    next
    edit 2
        set srcintf "port1"
        set dstintf "port2"
        set srcaddr "all"
        set dstaddr "Static_NAT_1to1"
        set schedule "always"
        set service "ALL"
        set comments "Used only to activate static Source NAT 1-to-1"
    next
end

Notes:

1) Even if no connections need to be initiated from external to internal, the firewall policy number 2 is required in order to activate the VIP range.

Otherwise, the IP address of the physical interface will be used for NAT.

In this example, it is set as a 'DENY' firewall policy for security purpose.

2) The set action deny statement is not shown in policy 2 as it is the default setting.
The NAT translation can be verified with a sniffer trace while pinging from the internal device to an external address:

# diagnose sniffer packet any "icmp" 4
[...]
65.163143 port2 in 10.10.10.42 -> 192.168.1.1: icmp: echo request
65.163164 port1 out 192.168.37.4 -> 192.168.1.1: icmp: echo request
65.163366 port1 in 192.168.1.1 -> 192.168.37.4: icmp: echo reply
65.163376 port2 out 192.168.1.1 -> 10.10.10.42: icmp: echo reply
[..]
75.790848 port2 in 10.10.10.44 -> 192.168.1.1: icmp: echo request
75.790852 port1 out 192.168.37.6 -> 192.168.1.1: icmp: echo request
75.791070 port1 in 192.168.1.1 -> 192.168.37.6: icmp: echo reply
75.791074 port2 out 192.168.1.1 -> 10.10.10.44: icmp: echo reply
[...]
138.492740 port2 in 10.10.10.46 -> 192.168.1.1: icmp: echo request
138.492759 port1 out 192.168.37.8 -> 192.168.1.1: icmp: echo request
138.492963 port1 in 192.168.1.1 -> 192.168.37.8: icmp: echo reply
138.500238 port2 out 192.168.1.1 -> 10.10.10.46: icmp: echo reply