Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
DMJLLX
New Contributor

Firewall VIP

Hello,

 

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... 

4 REPLIES 4
emnoc
Esteemed Contributor III

There's 3 things

 

  The diag debug flow might shed some light

 

  2nd you pretty much never need a  SNAT route on a policy-that's a VIP which the VIP is a DNAT function to begin with

 

  3rd can you shed the  configuration of the VIP and the firewall-policy?

 

 

But I would start with the diag debug flow to ensure the policy-id(s) in question are the ones you are interested in.

 

 

PCNSE 

NSE 

StrongSwan  

DMJLLX
New Contributor

 

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 57

config 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

    next

end

config 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

    next

end

 

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...

ehastings

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. 

Best Regards,   Eric Hastings, NSE3 | Systems Engineer (South Texas) Fortinet | Fast. Secure. Global.
ashukla_FTNT
Staff
Staff

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.