Date: Thu, 22 Feb 2024 01:53:37 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269770] libalias udp redirect_port temporary translation failure Message-ID: <bug-269770-227-7XoHG9c6md@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-269770-227@https.bugs.freebsd.org/bugzilla/> References: <bug-269770-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269770 --- Comment #2 from Peter Much <pmc@citylink.dinoex.sub.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-269770-227-7XoHG9c6md>