Telnet connection to cisco via Check Point

[Miktator]

When connecting to cisco via telnet protocol over fw r81.10 we are experiencing connection problems. namely, the connection does not happen at the first attempt within one connection, but from 3 or more, sometimes even from 10 times.
When connecting directly, everything happens from the first time

When connecting pyton script comes out an error "[WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection"
When connecting via cmd ".Could not open connection to the host, on port 23: Connect Failed." From 2 to 10 times and then it connects.

I added the host to the IPS exclusion but it did not help.
Please tell me where to look, maybe someone has already done this?

[Chris_Atkinson]

Sorry I have to ask why Telnet versus SSH and what do you see in logs / packet capture?

[Miktator]

Thank you for your attention to my problem.
I understand your concern about using telnet, but it is the customer's choice.
I only see accepts in the logs, so I didn't find any clues in my investigation.

[G_W_Albrecht]

I would suggest to contact TAC to get this resolved!

[PhoneBoy]

What precise device is the telnet coming from?
What does fw ctl zdebug drop say?
What does a tcpdump show?

[Miktator]

What precise device is the telnet coming from?
WindowsPC
What does fw ctl zdebug drop say?
@;1317998394;[cpu_2];[fw4_1];fw_log_drop_ex: Packet proto=6 DST_IP:23 -> SRC_IP:50684 dropped by fw_first_packet_state_checks Reason: First packet isn't SYN;
fw ctl zdebug+ drop
@;1317506904;[cpu_0];[SIM-209695455];do_inbound: Possible TCP state violation for <DST_IP,23,SRC_IP,50665,6> -> dropping packet ;
@;1317506904;[cpu_0];[SIM-209695455];sim_pkt_send_drop_notification: (0,0) received drop, reason: Invalid TCP option, conn: <DST_IP,23,SRC_IP,50665,6>;
@;1317506904;[cpu_0];[SIM-209695455];sim_pkt_send_drop_notification: no track is needed for this drop - not sending a notificaion, conn: <DST_IP,23,SRC_IP,50665,6>;
@;1317506904;[cpu_0];[SIM-209695455];do_packet_finish: SIMPKT_IN_DROP vsid=0, conn:<DST_IP,23,SRC_IP,50665,6>;
@;1317509016;[cpu_0];[SIM-209695455];update_tcp_state: invalid state detected (current state: 0x10000, th_flags=0x12, cdir=1) -> dropping packet, conn: [<SRC_IP,50665,DST_IP,23,6>][PPK0];

Where src_ip - windows PC and dst_ip - cisco2950.

What is noteworthy is that if the WinPC is connected through the router, without going through the Checkpoint, then the connection goes first time.
And if our WinPC connects to a cisco2960, which is located in the same network segment as the 2950, it also connects from the first time.

[Paul_Kazzi]

hi,

Reason: First packet isn't SYN;

You could possibly have an asymmetric routing issue. What does your topology look like?

[Miktator]

ARM->some router with ospf->eth1.100checkpoint->eth2.200checkpoint->some router with ospf->cisco2950
Reason: First packet isn't SYN i see on eth2.200 interface in logs from cisco to ARM.
From Arm To cisco i see only accept logs.

The problem would be easier to solve if the connection does not work at all, but the connection works, but not the first time. I have to make from 3 to 10 connections.
We use telnet because this cisco2950 has no other protocol.

I am curious why the 2960 works in the same network segment with no problems and connects the first time.

[Chris_Atkinson]

Do both the 2950 and 2960 have the same default gateway set?

[Miktator]

Yes I looked at the output of the trace command from both cisco to ARM.And from the gateway to both cisco.And all the hops match.

[PhoneBoy]

First Packet isn't SYN generally means it saw a packet for the connection AFTER the initial SYN packet.
That points to an asymmetric routing issue, as pointed out by others.
It could also be something funny with sequence numbers, as this SK suggests: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

[Miktator]

Thanks for the clarification.
Network experts say the route is symmetrical.

Unfortunately, I haven't been able to apply the solution from the sk for R81 with an error:

Get operation failed: failed to get parameter fw_trust_suspicious_establishment_conn

[PhoneBoy]

To get to the bottom of this, you're probably going to need a TAC case.

[Miktator · Accepted solution]

I found the solution in How to disable SecureXL for specific IP addresses (checkpoint.com).I added src and dst telnet connections to the exception.

Thank you for your time.

[Chris_Atkinson]

This is a workaround, you should contact TAC to understand why it changes the outcome and implement a proper fix.

Perhaps test again after applying the latest GA Jumbo hotfix if not already used.

[Miktator]

Yes we have the last JHF and I shared my workaround with TAC,if there is a direct solution I will be sure to add it.

[PhoneBoy]

The fact this "solves" the issue suggests what we stated earlier: asymmetric routing is likely to blame for this.
One thing SecureXL does is cache the ingress/egress interface to be used.
Disabling SecureXL for that specific connection would prevent any related issues.