CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 5 of 5

Thread: SAP and First Packet isn't SYN (R75.45)

  1. #1
    Join Date
    2011-12-15
    Posts
    11
    Rep Power
    0

    Default SAP and First Packet isn't SYN (R75.45)

    Hi everyone,

    we have reinstalled our VPN/Internet gateways (on open server) with R75.45 a few months ago.
    In general everything works fine but we have one strange little issue: SAP sessions are dropped randomly with "First Packet isn't SYN: PSH-ACK".
    From my point of view this seems wrong, because there IS a valid SAP session before, the user can work, and some time later it's dropped. From what I know SAP uses some kind of keepalive which may actually be the PSH-ACK packet.

    The packet and thus the session that is dropped is always coming from the SAP system. It is NOT a timeout issue since the timeout has been increased to 8 hours and this happens randomly after 10 minutes to a few hours.

    This happens for several different SAP systems and different users from different locations. It all comes together in our central VPN cluster.

    According to Check Point the gateway is acting as it should so I had to put a workaround with a user.def.Fiber in place (see sk11088).
    This works so far, but it can't be a permanent solution (especially since I have to create a policy that allows these packets).

    So long story short (TL;DR):
    SAP doesn't seem to work with R75.45. Any other experiences / ideas?

    Thanks
    Stephan

  2. #2
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,229
    Rep Power
    13

    Default Re: SAP and First Packet isn't SYN (R75.45)

    Quote Originally Posted by stdda View Post
    The packet and thus the session that is dropped is always coming from the SAP system. It is NOT a timeout issue since the timeout has been increased to 8 hours and this happens randomly after 10 minutes to a few hours.
    In the "First Packet isn't SYN: PSH-ACK" drop mesage, inspect the source/dest IP addresses, source port and service/destination port. Go back through your Tracker logs and figure out when that connection was actually started. You are assuming that connection was started "10 minutes" ago but I doubt it. Suppose you locate when the original connection was started, what is the time delta from connection start to the "First Packet isn't SYN: PSH-ACK" message? Is it consistently about the same value? That might provide a clue...

    Is the SAP system dual-homed to the network? Any chance there is an intermittent asymmetric routing condition that causes SAP traffic to occasionally bypass the firewall?

  3. #3
    Join Date
    2016-05-03
    Posts
    3
    Rep Power
    0

    Default Re: SAP and First Packet isn't SYN (R75.45)

    Quote Originally Posted by ShadowPeak.com View Post
    Is the SAP system dual-homed to the network? Any chance there is an intermittent asymmetric routing condition that causes SAP traffic to occasionally bypass the firewall?
    Sorry for the thread bump, but how do you check for intermittent routing conditions?
    ___________________________________
    Marius from Innovation Partner

  4. #4
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    265
    Rep Power
    12

    Default Re: SAP and First Packet isn't SYN (R75.45)

    Quote Originally Posted by Marius Titulescu View Post
    Sorry for the thread bump, but how do you check for intermittent routing conditions?
    That depends on which devices you control.

    Netflow or IPFIX would be the easiest way to definitively prove path changes. You just set it up on all of the switches and routers in the environment, and it will tell you exactly which devices handle a given connection. You would be looking for a traffic split between devices. For example, from A to B, 66% of traffic goes through devices X, Y, Z, but 33% goes through X, C, V, Z.

    If you control only the firewall and you suspect a routing change outside the firewall, an fw monitor could prove intermittent asymmetric paths. This could require a LOT of relatively manual data analysis. You would be looking for traffic flowing over different interfaces or to/from different MAC addresses, or weird sequence numbers indicating missing packets.

    If you control the firewall and suspect routing changes on it are causing a problem, you should be able to use 'ip monitor' to confirm. The 'ip' manpage has information on how to do this. I haven't done it on Linux before, but it sounds like 'route monitor' on OpenBSD, which simply prints every routing table change, with optional filtering.
    Zimmie

  5. #5
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,229
    Rep Power
    13

    Default Re: SAP and First Packet isn't SYN (R75.45)

    From my book:

    3. Configure the firewall to send a TCP RST packet to both participants of a
    connection that has been idled out. Upon receipt of the TCP RST, both
    participants instantly realize their connection is gone and launch a new one
    immediately to recover from the situation. To enable this feature “on the fly”, the
    command is fw ctl set int fw_rst_expired_conn 1. This setting will
    not survive a reboot, so to make it permanent you’ll need to see the following for
    more details: sk19746: How to force a Security Gateway to send a TCP RST
    packet upon TCP connection expiration.

    4. In some cases however #3 will not fully remediate the situation, and you will be
    forced to go one step further with this: fw ctl set int
    fw_reject_non_syn 1. A classic example of an application that requires this
    firewall setting is SAP HANA traffic. This setting also handles client port reuse
    out of state errors when RST packets from the server to the clients get lost (e.g.
    due to policy install or packet loss). Bear in mind however that this setting is
    quite likely to make your friendly auditor/penetration tester upset with you, since
    the firewall will now issue a TCP RST for all received packets that are out of
    state and have the ACK flag set. An auditor running a TCP ACK nmap scan will
    have it light up like a Christmas tree with tens of thousands of ports showing up
    as filtered instead of closed. For this reason, using this setting is generally not
    recommended on an Internet perimeter firewall, but may be acceptable on some
    internal firewalls.
    --
    Second Edition of my "Max Power" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

Similar Threads

  1. SecureXL problem: TCP packet out of state: First packet isn´t SYN tcp_flags: PUSH-ACK
    By mhernandez in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 4
    Last Post: 2014-09-18, 05:37
  2. TCP packet out of state: First packet isn't SYN
    By simono in forum Miscellaneous
    Replies: 4
    Last Post: 2009-10-22, 10:50
  3. TCP packet out of state: First packet isn't SYN tcp_flags: FIN-ACK
    By b0bby818 in forum Services (TCP, UDP, ICMP, etc.)
    Replies: 2
    Last Post: 2009-07-20, 05:21
  4. Replies: 0
    Last Post: 2009-07-16, 05:18
  5. Replies: 1
    Last Post: 2007-10-02, 11:41

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •