Stuck tcp session

[csystem]

Dear Fortinet community,

we recently migrated our server to use a Fortigate30e as firewall, since the old one couldn't handle the load, but we are encountering a problem in the way the new firewall handle tcp connections.

A bit of context: We have on our server a service that listen for incoming tcp connection from iot devices, this connection are short lived (a couple of packet) but get made every 5 second from each device.

The firewall is simply configured with a virtual ip mapped to our server via static nat and a couple of firewall rules.

What i see is that some tcp session get closed by the server but remain open on the firewall. this cause the following exchange between the device and server via the firewall built-in packed capture:

[ol]

The device keeps trying to open a connection (SYN), the firewall relays this packet to the server

The server accepts the connection (SYN-ACK)

 the firewall swallows the SYN-ACK packet, and does NOT relay this packet to the device

 the client doesn't see the answer to its SYN (since the firewall swallows it)

After a couple of second the client tries to open a new connection[/ol]

A couple of important notes:

- The device start a connection always from the same source port (11347) to the same server port (9000).

- if we end the session via the firewall, the device is able to connect to the server again.

- The device after a couple of connection attempts send a RST packet, but this too is ignored from the firewall.

- the server is a linux installation.

I think that the fact the device open the connection from the same port confuses the firewall.

How we make the firewall stop ignoring the SYN-ACK from the server to the device?  

Thank you

Andrew

[emnoc]

Why not fix the client application and open a new connection from a new tcp.port ? That would be the correct why vrs trying to make a application base firewall not "swallow the SYN-ACK'

Ken Felix

[csystem]

While i agree this is the simplest solution it's, unfortunately,  not possible.

Is there any other workaround to this problem?