For quite a while I've had multiple VIP's created mapping external IP's to internal IP's and it's been working just fine. The policy looks like port 16 (externel) all to switch (internal) VIP and set the service but NAT is not enabled. Everything works fine.
But now I created a DMZ on port 10, I created new VIP's mapping external IP to a new DMZ subnet and did everything the same as I did for the for the internal interface however it appears that NAT isn't working. If I enable NAT (use destination interface address) then things seem to work, able to use the service and ping but I shouldn't have to enable NAT in the policy. This also causes issues with the logs as everything appears to come from the IP address of port 10.
Why does VIP work when creating policies from external to switch (internal) but not when mapping to port 10? Hopefully this makes sense...I can always provide more detail...it's just strange...
2015-05-26 08:54:07 id=36871 trace_id=2443 msg="allocate a new session-4dd214d5"2015-05-26 08:54:07 id=36871 trace_id=2443 msg="find SNAT: IP-10.20.200.32(from IPPOOL), port-990"2015-05-26 08:54:07 id=36871 trace_id=2443 msg="VIP-10.20.200.32:990, outdev-port16"2015-05-26 08:54:07 id=36871 trace_id=2443 msg="DNAT 162.X.X.X:990->10.20.200.32:990"2015-05-26 08:54:07 id=36871 trace_id=2443 msg="find a route: gw-10.20.200.32 via port10"2015-05-26 08:54:07 id=36871 trace_id=2443 msg="Allowed by Policy-57:" show firewall policy 57config firewall policy edit 57 set srcintf "port16" set dstintf "port10" set srcaddr "all" set dstaddr "VIP I created" set action accept set schedule "always" set service "FTP/FTPS" set logtraffic enable nextendconfig firewall vip edit "WM-Demo_SFTP server" set extip X.X.X.X set extintf "port16" set nat-source-vip enable set mappedip 10.20.200.32 nextend The policy and VIP was not working...to get it working I enabled NAT (use destination interface address) in the policy and it's now working for the services I want. Of course the logs on the server show the same connecting IP... I also don't know why the above log shows "IPPOOL"...I haven't created any pools...
For the machine in the DMZ that you are VIP'ing to, can it get to the internet? If NAT inbound makes it work that makes it seem like a routing issue, or the machine doesn't know how to respond to the public host, but with NAT it responds to the DMZ IP which is in the same subnet. Make sure the DMZ host has the right subnet and default gateway, and the DMZ interface matches.
Eric Hastings, NSE3 | Systems Engineer (South Texas)
Fortinet | Fast. Secure. Global.
99% the default gateway on the dmz server is somehting other than the FGT dmz port ip.
Following is the logic why it works when source ip nat is enabled.
When we enable source nat to outgoing interface, the packet send out of FGT will have a same subnet ip as the server.
When server has to send a reply, server will see that source ip is from same subnet, so it will arp for the ip (which is FGT dmz ip), FGT will respond to arp and server will send the packet to firewall and firewall will forward the packet.
When we not doing source nat the source ip will be from other subnet and the server will send the packet to the default gateway, which looks like is not FGT, so packet will never reach back.
There are other chances, like firewall allowing only from same subnet etc, but i am pretty confident it is the default gateway misconfiguration.