Here to clarify the way a VIP address can be source natted on an external interface.
A Vip address could need to exit WAN1 using the same its IP address or using a dedicated ip pool, but the way to do it is not so obvious.
In some configuration the behavior of the VIP in SNAT, sometimes, could seems to work badly, for example the address could be source natted every time with its vip address also for internal traffic or not natted with its vip address but with the ip pools used by the policy.
Following all the different cases and the results shown
Initial configuration:
WAN1 Interface ip : 172.16.100.200/24
DMZ Interface Ip : 192.168.3.1/24
LAN Interface Ip : 192.168.2.1/24
VIP with extip 172.16.100.221 and mappedip "192.168.2.21"
config firewall vip
edit "vip_dc1"
set extip 172.16.100.221
set mappedip "192.168.2.21"
set extintf "any"
next
end
#policy from WAN1 to DMZ with VIP
edit 1
set srcintf "WAN1"
set dstintf "DMZ"
set srcaddr "all"
set dstaddr "vip_dc1"
set action accept
set schedule "always"
set service "ALL"
next
#policy from DMZ to WAN1
edit 2
set srcintf "DMZ"
set dstintf "WAN1"
set srcaddr "DC1"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
#policy from DMZ to LAN
edit 3
set srcintf "DMZ"
set dstintf "LAN"
set srcaddr "DC1"
set dstaddr "192.168.3.0/24"
set action accept
set schedule "always"
set service "ALL_ICMP"
set nat enable
next
To test how the vip address is source natted, we'll do a ping from the 192.168.2.21 to an external Ip (8.8.8.8) and to an client on LAN network : 192.168.3.100.
Then we get the result by the cli command "get sys session list"
Case 1 : Starting Point : Vip Address with option "interface any", outgoing policy with NAT interface
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 172.16.100.221:1 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
As you can observe the vip is Source Natted with its vip external address both on the external interface and internal.
Case 2 : Vip Address with option "interface any", outgoing policy with NAT Ip pool
Created two ip pools :
edit "ip_pool_192.168.3.200"
set startip 192.168.3.200
set endip 192.168.3.200
next
edit "ip_pool_dc1_172.16.100.199"
set startip 172.16.100.199
set endip 172.16.100.199
next
Applied to both the policies with nat:
edit 2
set srcintf "DMZ"
set dstintf "WAN1"
set srcaddr "DC1"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set ippool enable
set poolname "ip_pool_dc1_172.16.100.199"
set nat enable
next
edit 3
set name "DC1-INSIDE"
set srcintf "DMZ"
set dstintf "LAN"
set srcaddr "DC1"
set dstaddr "192.168.3.0/24"
set action accept
set schedule "always"
set service "ALL_ICMP"
set ippool enable
set poolname "ip_pool_192.168.3.200"
set nat enable
next
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 192.168.3.200:60417 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.199:60417 8.8.8.8:8 -
Good, my server going out using the ippool assigned to the policies, right behavior...
Case 3 : Vip Address with option "interface <WAN1>", outgoing policy with NAT interface
Ok now start from begging but first let's bind the vip address to the WAN1 interface:
config firewall vip
edit "vip_dc1"
set extip 172.16.100.221
set mappedip "192.168.2.21"
set extintf "WAN1"
next
end
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 192.168.3.1:60417 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
As you can see only the traffic versus WAN1 is source natted with its vip address but not the traffic natted on other interfaces.
So, to bind the vip address to interface plays main role in choosing the the source nat
Case 4 : Vip Address with option "interface <WAN1>", outgoing policy with NAT Ippool
Now let's use again the ipools asin the case 2
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 192.168.3.200:60417 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.199:60417 8.8.8.8:8 -
Ok same result as case 2, ipools wins over the "interface bind"
Case 5 : Vip Address with option "nat-source-vip enable" and "interface any", outgoing policy with NAT interface
Let's now to introduce the vip option "nat-source-vip enable".
This option will ever force VIP to EVER use its external ip for source nat when going out natted on a policy
Let's start again from begging but with the option "nat-source-vip" enabled:
config firewall vip
edit "vip_dc1"
set extip 172.16.100.221
set mappedip "192.168.2.21"
set extintf "any"
set nat-source-vip enable
next
end
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 172.16.100.221:1 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
As can you see the source nat is the extip on both session
Case 6 : Vip Address with option "nat-source-vip enable" and "interface any", outgoing policy with NAT Ippool
let's now add the ippools on the policy nat...
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 172.16.100.221:1 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
Same result...
Case 7 : Vip Address with option "nat-source-vip enable" and "interface <WAN1>", outgoing policy with NAT interface
Let's try to bind the vip to the outgoing interface:
config firewall vip
edit "vip_dc1"
set extip 172.16.100.221
set mappedip "192.168.2.21"
set extintf "WAN1"
set nat-source-vip enable
next
end
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 172.16.100.221:1 192.168.3.100:8 -
icmp 60 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
Again, the same result!
Case 8 : Vip Address with option "nat-source-vip enable" and "interface <WAN1>", outgoing policy with NAT Ippool
Let's a last try using also the ippools on the nat policies:
Result of "get sys session list":
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
icmp 59 192.168.2.21:1 172.16.100.221:1 192.168.3.100:8 -
icmp 59 192.168.2.21:1 172.16.100.221:1 8.8.8.8:8 -
Clearly the same result, as told before this option ever wins!
So, keep it in mind when you going to use it, because could lead to misconfigurations!ù
Do you have other experiences using it?
#fortigate #vip #SNAT
Hi Sergio,
Besides VIP and IPPools, you may also want to explore the behavior while using central nat. Some details are given in the articles,
Technical Note : Central NAT Table Usage and Behav... - Fortinet Community
Technical Note: Configuration changes regarding Ce... - Fortinet Community
Technical Tip: Configure firewall policies for a V... - Fortinet Community
Best regards,
Jin
Dear Sergio,
below you find the scenarios and which SNAT is used in which constellation :
1) VIP + central-nat + IP Pool - VIP has higher priority compared to central-nat table hence traffic will nat using VIP ip
2) VIP + nat-source-vip disable+ IP Pool+ no central nat - the traffic will nat using the IP Pool ip if the IP Pool is enabled on the firewall policy
3) VIP + nat-source-vip enable + IP Pool + no central nat - the traffic will be nat using the VIP ip even the IP Pool is enabled the on the firewall policy
4) Central-nat+ IP pool+ no VIP - traffic will be NATed using the central nat configuration
I hope this overview helps.
Best, Steffen
hi slautenschlager,
im using the 1st option from your idea. however i do have issue for it. seem only 1 pc could reach the destination with same destination but different IP pool
my environment is central nat problem for pointing same destination with different ip poo
in my case, there is configured different source, same destination with different Ip pool. However the result look no good.
for example, i tried use 2 machine for test, each assign to use different ip pool for SNAT. But only 1 workstation able to reach the destination with the ip pool, the other one unable reach at all.
i tried swap the sequence the rules, also no luck.
do you have the idea? would it fortigate don’t support this kind of design? or because snat session only allow occupied by 1 workstation. sound doesn’t make sense.
Hi ck,
hard to tell with this explanation without seeing your configuration.
Can you see session clashes in your logs that basically the same natted source port is used?
But as you are using different snat ippools might not be the issue.
I would recommend running a debug flow for the related addresses and raise a TAC ticket that we can analyze the output gathered there.
Please filter it for the second pc which is not able to reach the server.
Best, Steffen
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.