sqlnet1 Traffic Drop between Oracle hosts on same subnet. error: TCP First packet isn't SYN

[avramidisv]

Hi all,

I have a cluster R80.30 which is being running as a a default gateway for many downstream VLANS.

One of my VLANS host Oracle Applications and Databases. My issue is that i receive the following error when an Oracle App tries to communicate with an Oracle DB on the same VLAN.

TCP packet out of state:First packet isn't SYN
TCP Flags: PUSH-ACK
Source: 192.168.X1.X1
Source Port: 43950
Destination: 192.168.X1.X2
Destination Port: 1521
IP Protocol: 6

Blade: Firewall
Origin: Checkpoint-Core-FW1
Service: TCP/1521
Product Family: Access
Logid: 1
Interface: bond21.X1
Description: sqlnet1 Traffic Dropped from 192.168.X1.X1 to 192.168.X1.X2

Any advise?

Thank you in advance.

[PhoneBoy]

For a Check Point gateway to accept a TCP connection, one of two things must happen:

1. We need to see the entire TCP session from start to finish
2. You need to configure the gateway to allow "out-of-state" TCP connections (not recommended for security reasons).

If the traffic is truly on the same VLAN, the security gateway should never see this traffic to begin with.
Perhaps there is some sort of ARP issue with the database server that is causing it to send traffic to the gateway instead of where it's supposed to go.
That's where I'd look if I were seeing this.

[FedericoMeiners]

Hello,

By chance, are you load balancing your Oracle DB? I just had a customer which Oracle DB load sharing used two host which a different IP each. Fun thing was that both of them could reply to request of the other one and the GW dropped the traffic as out of state.

Do you always see the PUSH-ACK out of state? this flag my suggest time out, you may want to do some packet captures and maybe modify some TCP sessions.

If you cannot find the root cause of your issue I highly suggest to solutions from this post: Disabling 'out of state' checks between certain hosts 

Never ever disable stateful inspectin completly.

Hope it helps

______

[avramidisv · Accepted solution]

Thank you all for your advises.

It turned out that one of the machines had a  wrong subnet mask configured so the communication was directed through the firewall.

Problem solved.

thanks