FortiGate DNAT VIP Conversion

[johnlloyd_13]

hi,

just would like to confirm if my conversion below is correct?

it's for NAT between two internal networks in our environment to reach the MGMT subnet 172.29.0.0/16.

do i also use the "nat-source-vip enable" so the "mapped-ip" will be be used for SNAT in the reverse direction?

interface Port-channel101.61
 nameif outside
 security-level 0
 ip address 172.20.248.78 255.255.255.248

interface Port-channel101.60
 nameif inside
 security-level 100

 ip address 172.20.248.70 255.255.255.248

object network obj-172.16.7.70
 host 172.16.7.70
 nat (outside,inside) static 172.20.32.1

route outside 172.16.7.0 255.255.255.0 172.20.248.77 1

route inside 172.20.0.0 255.255.0.0 172.20.248.69 1

-----

config firewall vip
edit "vip-172.20.32.1"
set extip 172.20.32.1
set mappedip 172.16.7.70
set extintf "po1.60"

set nat-source-vip enable

end

config firewall security-policy
edit "DNAT for 172.20.32.1"
set srcintf "po1.60"
set dstintf "po1.61"
set srcaddr "any"
set dstaddr "vip-172.20.32.1"
set service "ALL"
set schedule "always"
set status enable
set action accept
set nat disable

end

[Stephen_G]

Hello,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[Christian_89 · Accepted solution]

Below is a summary of the main points to double-check when converting an ASA-style static NAT (DNAT) into a FortiGate VIP, including the question about `nat-source-vip enable`. Hopefully this helps confirm you’re on the right track.

1. Matching the IP Addresses and Interfaces

From your sample ASA config:

object network obj-172.16.7.70
host 172.16.7.70
nat (outside,inside) static 172.29.32.1

this indicates that traffic arriving on interface `outside` (and addressed to `172.29.32.1`) should be translated to the real IP `172.16.7.70` on the interface `inside`, and vice versa. Make sure the VIP on your FortiGate references the same “external” IP (the one users or hosts will connect to) that the ASA was using.

 Common Gotcha
In your FortiGate config, you used:

edit "vip-172.20.32.1"
set extip 172.20.32.1
set mappedip 172.16.7.70
set extintf "po1.60"

But in the ASA config, the mapped IP was `172.29.32.1` (not `172.20.32.1`). If that’s just an example, no problem—just be sure the “external IP” in the VIP (`extip`) matches what was publicly/externally used before (i.e., `172.29.32.1` if that’s the real NAT address).

Likewise, confirm that `po1.60` on the FortiGate is truly the interface from which traffic will arrive for `172.29.32.1` (i.e., the old ASA “outside” equivalent). FortiGate VIPs must use the interface on which you expect the original (destination) traffic.

2. Policy Configuration and Directions

A typical VIP policy for inbound DNAT looks like this:
```plaintext
config firewall policy
edit <ID>
set name "DNAT to 172.16.7.70"
set srcintf "outside-interface"
set dstintf "inside-interface"
set srcaddr "all"
set dstaddr "vip-172.29.32.1" <-- the VIP object
set service "ALL"
set schedule "always"
set action accept
set nat disable <-- normal for VIP-based DNAT
next
end

`nat disable`** is correct for DNAT policies that rely on a VIP. The VIP itself handles the address translation.
- **Ensure the “dstintf”** is the interface where the real server resides (inside or DMZ).

3. `nat-source-vip enable` for Symmetric NAT

By default, a DNAT VIP only translates the destination address as traffic enters the FortiGate. If you want the replying server’s source address to be translated back to the VIP’s external IP (i.e., a fully symmetric 1:1 static NAT), then setting `nat-source-vip enable` is correct. This ensures that traffic egressing back out to the client will have the source IP of your “extip” rather than the real server IP.

In other words:
Without `nat-source-vip enable`: Return traffic from `172.16.7.70` would go back to the client showing `172.16.7.70` as the source. This is fine if the client can route to `172.16.x.x` but can break if the client expects replies from the same IP it used to connect (i.e., `172.29.32.1`).
With `nat-source-vip enable`: Return traffic from `172.16.7.70` is translated back to `172.29.32.1` (the VIP) so the entire connection is symmetrical from the client’s perspective.

Most ASA-style static NATs are symmetrical by default, so you typically do want `nat-source-vip enable`.

4. Routing Checks

You mentioned:

route outside 172.16.7.0 255.255.255.0 172.20.248.77 1
route inside 172.29.0.0 255.255.0.0 172.20.248.69 1

Make sure your FortiGate has proper routes (or connected interfaces) that allow:
- traffic from the “outside” interface to reach 172.16.7.70 (after being DNATed), and
- return traffic from 172.16.7.x to route back out toward the “outside” (or whichever VLAN carries that NATed traffic).

If the FortiGate is routing between two internal VLANs, confirm that each VLAN sees the FortiGate as the next-hop for the other subnet.

 5. Putting It All Together

Yes, your FortiGate VIP config looks structurally correct for DNAT if:
1. `extip` matches the IP you want clients to use (e.g., `172.29.32.1` instead of `172.20.32.1` if that’s truly the address from the ASA config).
2. `extintf` is set to the correct VLAN or interface where inbound traffic to `extip` arrives.
3. **`nat-source-vip enable`** is used if you need a fully symmetric NAT (source address on return traffic is also translated).
4. Your policy is set to `nat disable` because the VIP is doing the translation.

Finally, do not forget to test from a client on the “outside” (or whichever subnet expects to see `172.29.32.1`). If everything is correct, you should be able to reach `172.16.7.70` via `172.29.32.1`.

Summary

Yes, using `nat-source-vip enable` is generally correct if you want the real server’s outbound packets to get translated back to the same VIP address.
- Double-check that the VIP’s external IP, interface, and the policy directions match how traffic really flows in your network.
- Ensure your IP addresses in FortiGate VIP match the ASA’s original static NAT addresses so you preserve the same behavior.

That should replicate your original ASA static NAT (DNAT) setup on FortiGate. Good luck with the migration!

[johnlloyd_13]

hi,

thanks for the detailed response! appreciate it.