Skip to main content
FedeS
FedeS
Explorer
April 16, 2025
Question

Fortigate 60E blocks keepalive messages

  • April 16, 2025
  • 2 replies
  • 2145 views

Hello,

my company has a web service that sends keepalive messages every 20seconds, the web server is out of our network, it is on Azure Cloud.

If i send keepalive from my network the messages I sent don't arrive on the server

If i send keepalive out of my network (with a notebook connected to my phone), I can see the keepalive messages on the server.

To sniff the traffic on the sever I used wireshark.

On the firewall I can't see the keppalives going through.

 

Thank you!

 

2 replies

syordanov
Staff
syordanov
Staff
April 16, 2025

Hello FedeS,

 

To narrow down the problem, first step is do do a sniffer for the keepalive messages on the FortiGate, use the sniffer bellow :

 

diagnose sniffer packet any " host x.x.x.x " 4 0 l <---- replace x.x.x.x with the IP address of web service

This will show is the traffic is received on FortiGate and forwarded to the ISP/WAN interface.
Additionally , you could check the session list if the session is created using the commands bellow :

 

diag sys session filter dst XXXXX.XXXXX.XXXX.XXXX <---- destination IP/web servuce

diag sys session filter dport XXX <----

diag sys session list


 

Best regards,

 

Fortinet

    FedeS
    FedeSAuthor
    Explorer
    April 16, 2025

    Hi Syordanov and thanks for your reply!

    In wireshark I see clearly when a packet is keepalive or not

     

    keepalive.png

     

    Is there a way to see them clearly also on Fortigate? 

     

    With traffic sniffer I can see psh and ack, and I suppose they are keepalive messages

     

    Thank you!



    syordanov
    Staff
    syordanov
    Staff
    April 16, 2025

    Hello FedeS,

     

    Is this Wireshark output taken on FortiGate or clould provider?

    Did you get the output from the session list? From there we can see if the session is created/allowed on FortiGate.

    I think this TCP Kee-Alive is for already established session, which means that the 3 way handshake is established.

     

    Best regards,

    Fortinet

      syordanov
      Staff
      syordanov
      Staff
      April 17, 2025

      Hello FedeS,

       

      From the provided output the session is created(3 way hand shake) and we have 2 way direction traffic.

      My suggestion like dingjerry_FTNT:

       

      1) Disable the offloading on FW rule No1:

      2) Run a sniffer like  on SSH1:

       

      diagnose sniffer packet any " port 52076" 4 0 l

       

       

      3) On SSH No2:

      diag sys session filter dst XXXXX.XXXXX.XXXX.XXXX <---- destination IP/web service

      diag sys session filter dport 52076<----

      diag sys session list

      diag sys session clear

      diag sys session list


      With point No3 you will list the session and then clear it , meanwhile SSH No1 will capture the new TCP handshake  / traffic to/from server.

      If there is UTM profile on rule No1 like APP control , IPS or any other , to create a separate rule on top of the ruleset only for the affected source/destination or disable them on the rule.

       

      Thank you!

       

      Best regards,

       

      Fortinet

       

      Terms & ConditionsAccessibility statement