> Source: [sk121933](https://support.checkpoint.com/results/sk/sk121933) # sk121933 - Dropped UDP Server to Client packets refresh the connection timeout | Property | Value | |----------|-------| | Solution ID | sk121933 | | Date Created | 2017-12-19 | | Last Modified | 2023-06-02 | | Technical Level | General | | Products | Security Gateway | | Versions | R81.20, R81.10 (EOS), R81 (EOS) | | OS | Gaia | ## Symptoms - * UDP packets from Server to Client are dropped by the Security Gateway, as mentioned in [sk103598](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk103598). * Kernel debug (fw ctl zdebug + drop) shows: `;[fw4_0];fw_log_drop_ex: Packet proto=17 192.168.100.10:12000 -> 192.168.200.10:12000 dropped by fw_handle_old_conn_recovery Reason: UDP packet that belongs to an old session;` * The connection timer is reset by the dropped packets. ## Cause There is an existing session table entry for this session. By default UDP is a sessionless protocol and by design Check Point creates a virtual session for UDP. If a server creates a session to a client, for the client it's not possible to initiate a same session with the same IP:Port combination. ## Solution The reset of the connection timer by a UDP packet that belongs to an old session, is an expected behavior. The existing behavior should not cause any issues - either the server will give up and the connection will reset, or the client will send a packet to the server. To verify that this is the issue in your case: * Examine the connections table and find the relevant session. For example if source ip is 1.1.1.1 and the destination ip is 2.2.2.2 Convert the IP addresses to HEX as follows: 1.1.1.1 to HEX is **01010101** 2.2.2.2 to HEX is **02020202** * Run the command to find the connection on the Connections Table: \[Expert@gw1:0\]#fw tab -t connections -u \| grep **01010101** \| grep **02020202** \<**00000000, 01010101, 000013c7, 02020202, 000013c4, 00000011** \> -\> \<00000000, 02020202, 000013c4, 01010101, 000013c7, 00000011\> (00000006) \<00000001, 01010101, 000013c7, 02020202, 000013c4, 00000011\> -\> \<00000000, 02020202, 000013c4, 01010101, 000013c7, 00000011\> (00000005) \<00000001, 02020202, 000013c4, 01010101, 000013c7, 00000011\> -\> \<00000000, 02020202, 000013c4, 01010101, 000013c7, 00000011\> (00000002) \<00000000, 02020202, 000013c4, 01010101, 000013c7, 00000011; 00010001, 00006180, 0000019c, 00000028, 00000000, 59e756b9, 000001a5, 5301f704, c0000006, 00000018, 00000018, 00000036, 00000036, 02000000, 00002000, 00000004, 00000000, 00000000, 00000000, 00000000, 00000000, c4f2b80a, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000,37/40\> See [sk65133](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65133) to for details on the connection table. * In lines one and two there are the symbolic links to the dropped connection. Line four is the root cause for the drop. This is the entry with a wrong direction. * Check Point creates a virtual session for UDP and see the server to client connection as client to server connection. If the real client try to open a new client to server connection the firewall drops it, because a session are already exists. To delete the wrong table entry use following command: 1. \[Expert@HostName\]# fw tab -t connections -x -e DIRECTION,SOURCE_IP,SOURCE_PORT,DEST_IP,DEST_PORT,PROTOCOL Based on above example: fw tab -t connections -x -e **00000000,01010101,000013c7,02020202,000013c4,00000011** 2. If the customer would like to mitigate this issue, they can add a kernel parameter to rematch the udp connection. For example if this issue is happening for DHCP traffic, they can add the following to the $FWDIR/boot/modules/fwkern.conf file. fwconn_rematch_udp_s2c_old_conn=1 fwconn_rematch_udp_s2c_old_conn_by_service=67 3. In case the customer would like to change this behavior, a Hotfix can be obtained. Please [Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) to get a Hotfix for this issue. A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix. For faster resolution and verification please collect [CPinfo](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92739) files from the Security Management and Security Gateways involved in the case. **In case you want to rematch more than one UDP port, this feature was added to:** * [Check Point R80.20](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk122485) * [Jumbo Hotfix Accumulator for R80.10 (R80_10_jumbo_hf)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk116380) from Take 177 Check Point recommends to always upgrade to the most recent version ([upgrade Security Gateway](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=435) / [upgrade Cluster](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=428) / [upgrade Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=184) / [upgrade Multi-Domain Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=166)). **Instructions:** **On Management side:** To the relevant **user.def.X** file Add the line: (see sk98239 - Location of the relevant user.def.X file will be determined by the MGMT and GW Versions - ) fw_udp_rematch_services = { \ , \, \, ... }; \*\*There shouldn't be a comma at the end, the above example is just simulating more Services after the third Service. **Example:** fw_udp_rematch_services = { \<5060\> , \<5063\> }; **On the Gateway:** Add the below line to $FWDIR/boot/modules/fwkern.conf : fwconn_rematch_udp_s2c_old_conn=1 (no more need for: fwconn_rematch_udp_s2c_old_conn_by_service X, it can be removed as ports to be rematch will be pushed from MGMT side) To allow the rematch of all UDP ports (not just the manual entries on the management side), edit the connection persistence to be "keep all connections": ![](https://sc1.checkpoint.com/sc//SolutionsStatics/sk121933/keep all1904151936.jpg) **Related solution:** [sk103598 - Connectivity Issues after Policy Install](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk103598) --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content