Fortigate 40F VIP not working for same network

[Kennylin]

Hi all, 

We have a Fortigate 40F (7.6.x) with the following configured:

1) WAN x.y.z.138 public address (connected to Internet)

2) LAN 192.168.1.254

3) VIP : x.y.z.136 --> 192.168.1.6 

4) Two firewall rules: one allowed all sources to access the VIP , the other allowed x.y.z.0/24 to access the VIP

The VIP forwarding is working fine except for client with x.y.z.133 (same network with Fortigate's WAN), from which all requests are just time-out and no response.

Any idea is appreciated !

Kenny Lin

[esalija]

Hi @Kennylin 

To troubleshoot the issue where a client with the IP address x.y.z.133 is unable to access the VIP, follow these steps:

1. Ensure that the firewall policy allowing access to the VIP is correctly configured and prioritised. The policy should allow traffic from the source IP x.y.z.133 to the VIP.
2. Verify that the VIP is correctly configured to map the external IP x.y.z.136 to the internal IP 192.168.1.6. Ensure that the port forwarding settings are correct if applicable.

3. Confirm that there is a valid route for the traffic from x.y.z.133 to reach the FortiGate and that the return path is correctly configured.
4. Check for Overlapping Subnets: Ensure there are no overlapping subnets or IP conflicts that might be causing routing issues.

Debugging:

Use the following debug commands to gather more information:
diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr x.y.z.133
diagnose debug flow trace start 255
diagnose debug enable

Initiate traffic from x.y.z.133 and observe the debug output for any anomalies or errors.

Stop Debugging:

Once you have gathered enough information, stop the debug process:

diagnose debug disable
diagnose debug reset

- Review the FortiGate logs for any denied traffic or errors related to the client IP x.y.z.133.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Restrict-the-traffic-to-VIP-for-specific-g...
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-VIP-access-where-specific...

Best regards,
Erlin

[syordanov]

Hello Kenny ,

I hope you are doing well. It will be useful if you run the following debug when the user is testing the access from x.y.z.133 to x.y.z.136 , please use the following debug :

diagnose debug reset

diagnose debug disable

diagnose debug flow trace stop

diagnose debug flow filter clear

diagnose debug flow show iprope enable

diagnose  debug  flow show function-name enable

diagnose debug flow filter saddr x.y.z.133  <--- source IP 

diagnose  debug  console timestamp enable

diagnose debug flow trace start 1000

diagnose debug enable

---

Once the debug flow is started, please test the access from x.y.z.133 (you can replace the source and VIP external IP addresses with x.y.z.133 and x.y.z.136 ).

To stop the debug, please run :

diagnose debug reset

diagnose debug disable

Thank you.

Fortinet

[Kennylin]

Thanks Erlin and syordanov for quick reply.

I tried to fetch the debug messages as you guided, and check it out carefully.

But not able to find anything wrong. 

Could you guys help ? https://drive.google.com/file/d/1CPxLI_bB9O5SVYiyikRmrR2oc-tj6g6f/view?usp=drive_link

Thanks again,

Kenny

[syordanov]

Hello Kenny,

Thanks for the logs.
So based on them source is x.y.z.133, destination is x.y.z.136 over TCP 80.

Because of the DNAT, x.y.z.136 is translated to 192.168.1.60, traffic is allowed by policy No 6, for this policy is configured an IPpool , so the source x.y.z.133 is translated to 192.168.1.254. The rest of the debug flow shows a reply/return traffic which matches the existing session ID 000140cf.

id=65308 trace_id=26 func=print_pkt_detail line=6144 msg="vd-root:0 received a packet(proto=6, 192.168.1.6:80->192.168.1.254:62652) tun_id=0.0.0.0 from lan. flag [S.]
, seq 3864994380, ack 575585442, win 28960"id=65308 trace_id=26 func=resolve_ip_tuple_fast line=6252 msg="Find an existing ses
sion, id-000140cf, reply direction"
id=65308 trace_id=26 func=__ip_session_run_tuple line=3542 msg="DNAT 192.168.1.254:62652->x.y.z.133:62652"
id=65308 trace_id=26 func=vf_ip_route_input_common line=2615 msg="find a route: flag=80000000 gw-x.y.z.133 via root"

My suggestion is to check the KB bellow and enable the 'set nat-source-vip'

    set nat-source-vip enable

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Mapping-VIP-outbound-connections-Source-NA...

With that in mind, the following is the order of preference that the FortiGate uses when determining which IP address (IP Pool, VIP, Outgoing Interface Address) to use when Source NAT'ing traffic. Note that this list assumes that traffic could already potentially match any three of the options:

1. VIP External Address (when nat-source-vip -> enable)**
2. IP Pool assigned to Firewall Policy.
3. VIP External Address (when nat-source-vip -> disable; default setting)
4. Outgoing Interface IP.
Note:

When nat-source-vip is enabled, the VIP external address will be used for all traffic from the mapped-host that is being Source NAT'd, even if traffic is egressing from a different interface than the VIP is configured for (and even if other VIPs match that mapped-host). Use this option with caution.

Thank you,

Fortinet

[Kennylin]

Hi syordanov,

Thanks for your solution.

I tried to enable "nat-source-ip" for the VIP, but still not working.

Another finding is that when I connect the VIP with x.y.x.134, it works just fine !

The x.y.z.133 is actually another gateway for the office staff, with NAT capability.

So I am wondering the issue must be related to NAT in some layer.

There is a "NAT" switch for the firewall policy, I tried to turn it on and off, but neither works. New debug log is recorded with NAT turned off (firewall policy 6): https://drive.google.com/file/d/1Xf1wGeJTtFwCfunPWXvn2qebgo6OEZF0/view?usp=sharing

Thanks,

Kenny

[syordanov · Accepted solution]

Hello Kennylin,

Thanks for the new logs. Again FortiGate creates a new session (session ID 0009159e) , DNAT is triggered correctly, but the RST packet looks strange, because it's locally generated : 

2025-11-12 12:44:53 id=65308 trace_id=64 func=print_pkt_detail line=6144 msg="vd-root:0 received a packet(proto=6, x.y.z.133:56745->192.168.1.6:80) tun_id=0.0.0.0 from local. flag [R], seq 4107502239, ack 0, win 0"
2025-11-12 12:44:54 id=65308 trace_id=65 func=print_pkt_detail line=6144 msg="vd-root:0 received a packet(proto=6, x.y.z:56745->211.72.106.136:80) tun_id=0.0.0.0 from wan. flag [S], seq 4107502238, ack 0, win65535"

Please check the KB bellow :

https://community.fortinet.com/t5/FortiGate/Technical-Tip-IP-pool-and-virtual-IP-behavior-changes-in...

It will be good if you can open  a ticket to TAC.

Thank you

Fortinet

[Kennylin]

Hi syordanov,

Turned out that the root cause is IPPool you mentioned !

We set up an IPPool for "x.y.z.133" weeks ago when trouble-shooting another issue.

Everything works just fine after the IPPool removed !

Many thanks !

Kenny