Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Miktator
Contributor

Telnet connection to cisco via Check Point

Jump to solution

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?

0 Kudos
1 Solution

Accepted Solutions
Miktator
Contributor

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.

View solution in original post

0 Kudos
16 Replies
Chris_Atkinson
Employee
Employee

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

0 Kudos
Miktator
Contributor

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.

0 Kudos
G_W_Albrecht
Legend
Legend

I would suggest to contact TAC to get this resolved!

CCSE CCTE SMB Specialist
0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
Miktator
Contributor

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.


0 Kudos
Paul_Kazzi
Participant

hi,

Reason: First packet isn't SYN;

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

0 Kudos
Miktator
Contributor

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.



0 Kudos
Chris_Atkinson
Employee
Employee

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

0 Kudos
Miktator
Contributor

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.

0 Kudos
PhoneBoy
Admin
Admin

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... 

0 Kudos
Miktator
Contributor

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

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
Miktator
Contributor

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.

0 Kudos
Chris_Atkinson
Employee
Employee

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.

0 Kudos
Miktator
Contributor

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.

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos