From nobody Thu Feb 22 01:53:37 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TgGQ95MY9z5BYvs for ; Thu, 22 Feb 2024 01:53:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TgGQ9438xz4nYX for ; Thu, 22 Feb 2024 01:53:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708566817; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qjBwUFSCVH1QkYveQhAID6idOxbqidfzU8nByXoLC4M=; b=nuVwZAF2d/4EHRRIevOym7tp9x3oGqIHFCfgoX8S8Wa5nRKF7BFFI0zLr7ywSn3CjpH70i /Ft8EsvICvj0NW0MsZ0PuouYwNghG0k5dy6j8fuyDwvkwybINLtONeB7aTKGqxrxzeBrXP w3FTb0olNLC1NQkZSsRdfo50D0rNEAJuu2tG0CebwlmzBssXgwdSWT1PKEyUmDG46oCNhq 3kmfQhQ1GrIDacJoVQ7xDIRJKDZLvI7QEoxHiOOqtk43xZSFM5Ml27O+DHCOuw9x2DgO4t cvje4Ymk05tsiid9XE7xZ0C+HQefpLvpAvipGGuGKKtg10DdOvT2VchIcO7QsA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708566817; a=rsa-sha256; cv=none; b=aF0YtUSMg+hjQkCBMswtv6LLgfcevgMVk6fsDMmoPUhbnQbLgEgkXufAppZVd4fotqZiQQ vO6rAofSWG5AFtBowWDCmlZhBF3uecEMNLFiZ+uOAXsbceHPlAduIVycm46U4MtEfCYce9 jOjwNQ9pxkgF55/KBayPedMnKnQO0lW8bpQoju3QCfe/JmgXhoLpIHgIspTaf+PpKsvvXL 9wdCeombWXJ5LXiZQASAPMsmbEiQ5GQ0B1BE9TRVQrVD76y8DQPEKfZ40s/jHQsKKQPMHT wwex1UYUt+VHnkTrwaqg/jUIi5G+UnbNSEVSf60QglC5zcdAUyasNg5xkKntHA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TgGQ936svz1RcY for ; Thu, 22 Feb 2024 01:53:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 41M1rbIo033251 for ; Thu, 22 Feb 2024 01:53:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41M1rbVX033250 for bugs@FreeBSD.org; Thu, 22 Feb 2024 01:53:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269770] libalias udp redirect_port temporary translation failure Date: Thu, 22 Feb 2024 01:53:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pmc@citylink.dinoex.sub.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269770 --- Comment #2 from Peter Much --- I managed to analyze this a bit further: With an UDP service (e.g. VPN) portforwarded behind NAT there is no notion = of a connection, and apparently it can happen that libalias creates TWO distinct records for inbound and outbound traffic, with the inbound record lacking t= he portforward (and the received packets then dumped as undeliverable on the NATing node). The problem always resolves itself after either 12 or 14 minutes, apparently due to internal timings. Observed with dtrace (cmdline is attached): 203.0.113.1 is my public address where NAT aliases to 198.51.100.1 is the address of the connecting client from outside 192.168.1.12 is the internal address of the VPN server (where portforward = goes to) -> At this time we have a packet client->server, two server->client and ano= ther client->server, all successful 18 17832 DeleteLink:entry openvpn 1708555176 icmp=3D5 udp= =3D2 tcp=3D108 type=3D17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0) (alias_addr 0.0.0.0) (proxy_addr 0.0.0.0) (src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0) -> For whatever reason libalias tries to delete some UDP, but the next line shows that nothing was actually deleted. So this would apparently be the permanent portforward, there is no other codepath 18 49947 AddLink:entry openvpn 1708555180 icmp=3D5 udp= =3D2 tcp=3D108 -> At this time we get a packet client->server, and it is the first failing= (it gets processed by libalias, but NOT portforwarded (in the next second we al= so get packets in the other direction, so without fractional seconds logged we do not know when exactly what happened)=20 18 17832 DeleteLink:entry openvpn 1708555186 icmp=3D5 udp= =3D2 tcp=3D111 type=3D17 (src_addr 192.168.1.12) (dst_addr 198.51.100.1) (alias_addr 0.0.0.0) (proxy_addr 0.0.0.0) (src_port 5007) (dst_port 8211) (alias_port 5006) (proxy_port 0) -> Here the portforward got deleted (but WHY? It is continuousley used, pin= gs every 10 seconds), and udp count goes to 1. 18 49947 AddLink:entry openvpn 1708555186 icmp=3D5 udp= =3D1 tcp=3D111 (src_addr 203.0.113.1) (dst_addr 91.62.14.110) (alias_addr 203.0.113.1) (src_port 5006) 18 49948 AddLink:return openvpn 1708555186 icmp=3D5 udp= =3D2 tcp=3D111 type=3D17 (src_addr 203.0.113.1) (dst_addr 198.51.100.1) (alias_addr 203.0.113.1) (proxy_addr 0.0.0.0) (src_port 5006) (dst_port 8211) (alias_port 5006) (proxy_port 0) -> And immediately added again, but now WITHOUT the portforward!! 19 17832 DeleteLink:entry suricata 1708555186 icmp=3D5 ud= p=3D2 tcp=3D111 type=3D17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0) (alias_addr 0.0.0.0) (proxy_addr 0.0.0.0) (src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0) -> Apparently the housekeeping is too aggressive... 19 49947 AddLink:entry suricata 1708555186 icmp=3D5 ud= p=3D2 tcp=3D111 (src_addr 192.168.1.12) (dst_addr 198.51.100.1) (alias_addr 0.0.0= .0) (src_port 5007) 19 49948 AddLink:return suricata 1708555186 icmp=3D5 ud= p=3D3 tcp=3D111 type=3D17 (src_addr 192.168.1.12) (dst_addr 198.51.100.1) (alias_addr 0.0.0.0) (proxy_addr 0.0.0.0) (src_port 5007) (dst_port 8211) (alias_port 5006) (proxy_port 0) -> And now we get the portforward as a *SEPARATE* record (udp went to 3!)=20 19 17832 DeleteLink:entry suricata 1708555186 icmp=3D5 ud= p=3D3 tcp=3D111 type=3D17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0) (alias_addr 0.0.0.0) (proxy_addr 0.0.0.0) (src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0) -> groundhog day again --=20 You are receiving this mail because: You are the assignee for the bug.=