Skip to main content
Kennylin
Kennylin
New Member
November 10, 2025
Solved

Fortigate 40F VIP not working for same network

  • November 10, 2025
  • 3 replies
  • 1078 views

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

Best answer by syordanov

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-FortiOS/ta-p/277823

 

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

 

Thank you

Fortinet

3 replies

esalija
Staff
esalija
Staff
November 10, 2025

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-group-of/ta-p/406793
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-VIP-access-where-specific-source/ta-p/265748

Best regards,
Erlin

    syordanov
    Staff
    syordanov
    Staff
    November 10, 2025

    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
      KennylinAuthor
      New Member
      November 10, 2025

      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
      Staff
      syordanov
      Staff
      November 11, 2025

      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-NAT/ta-p/193423

       

       

      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
        KennylinAuthor
        New Member
        November 12, 2025

        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

        Terms & ConditionsAccessibility statement