From nobody Tue Dec 02 02:38:44 2025 X-Original-To: freebsd-net@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 4dL4hz6cHfz6JLG9 for ; Tue, 02 Dec 2025 02:38:59 +0000 (UTC) (envelope-from morganw@gmail.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dL4hz25wnz3xTK for ; Tue, 02 Dec 2025 02:38:59 +0000 (UTC) (envelope-from morganw@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=fCpgasW5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of morganw@gmail.com designates 2a00:1450:4864:20::231 as permitted sender) smtp.mailfrom=morganw@gmail.com Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-37b935df7bfso46288041fa.2 for ; Mon, 01 Dec 2025 18:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764643136; x=1765247936; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=xkFsEkHqmbvEXCDrONAmqJPvPF1/wusOU5+UG//FIkk=; b=fCpgasW5Zf/stZtwCrLjuO9CQe+Ko1u7ZZ04+LiheokqI172jGr1x5zUiBea1Eaaqe QKL30vlcsM+7LTA15fHoWdGHcsfHpMiEQZG0r1D0i8Nrv8mYlNdZlhpbIC7AyWjoKOkX gZKsWx7lo1tg3Nk1Lf8QSYGUp3rWZs3+3tpOtQOwBj9oLdFzLCcjMTAM1awq4iuGEzHp wJanM4GPw4HL551+3je6MpoSwGDUn0NfzCz4FgVCEDiNDp60q6hJbsn8RI9qZ6oyVJu7 T0nT5QkbGpolImg5yvBv+h6p71jWNuo+/UyKStWT2J2J/DU3jghAdbB9t2tDQD7Z1YL6 /oNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764643136; x=1765247936; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xkFsEkHqmbvEXCDrONAmqJPvPF1/wusOU5+UG//FIkk=; b=rcgyorDGbce0zViD3qp7lVk8IB+dJIijeoPVYZJHkMzQs0WLyzY3afYsuadSfIKDB2 LkhvlAdOkcHqgc+u2umVunjOr8j0PQpZ5zIFOo7yZ4SaKdCFywxFCsICNEuWED6t1PKM LWfBSCeiJ/ycEtz1s4f+EHVPp8YzvQFn7OUuDQrEodv6OihAZYTmUwOAldxqaXDM8Yu5 JHrSXYhysrqr7s+AYhf9jPBRC2pXIu3TjKNSq2dnu2w0BjPgBNr+6wBe4poT814bNqiU /syY8Of+rhVwDM97wECKAQr1c7M2pkSdr5/+ckA+X1amSwiGrK1vC0wFy4obYp5u8gJi 7Dtg== X-Gm-Message-State: AOJu0YyIVBn4hYqm6udRghxEGtKE5JNk+rcfSLrFdyLTCkG+q+EEY+HC VT0nq6iNtjunX/Ysg0nmbkCK0UQ+g04CWGXvIF1Jq5XFYWWPkfZwKCvv6ij7p/ep7yoHGE8+sMd RRYqjPiymxJA18BVKetx7ceDVdTP4MbXMvw== X-Gm-Gg: ASbGncuVFu3iHwBdWXnQjeQcrGyvHCfN+qo6ef8MeSu0HoOSMjSBL+7en8tuGdlJlpV Pbqwy7E+YL0JMdn7CZF60NnAXYuYezPa+GXk0HxhpBqKE21Kqzg54U5XHrW6eplC9a9MZCatdg2 pPC4wSXE+LTmZvvnLM1F7F2cpPNBAzBrfwF7RO3Z+xil4wVUCecknxOZJY2TxqoIpQ0VJg5HcCN SyVZAy42za0KQmbsrHNRnC1h88O0yTI6JnNr8QgQBwmg7CQE0B+NU9oACmy6JciY+SvDXsI X-Google-Smtp-Source: AGHT+IEi0l8N0O5VrvCQv9YoOaPMOQ2/rkz7vZlYeMekC6QEVUbn9MJqj8vNQtHvdGz4gK57iADuk0k+yZtVucatIPs= X-Received: by 2002:a2e:780e:0:b0:37b:90fb:9caf with SMTP id 38308e7fff4ca-37cd92a61d5mr82252261fa.41.1764643135844; Mon, 01 Dec 2025 18:38:55 -0800 (PST) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 From: Wes Morgan Date: Mon, 1 Dec 2025 20:38:44 -0600 X-Gm-Features: AWmQ_blRziP4KoWAMfdPchU9-GOh_3KUXcLzWItNu_kRJ3awz8iMkup5B9shrVs Message-ID: Subject: RST Packets bypass wireguard interface To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.02 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.09)[-0.095]; NEURAL_SPAM_MEDIUM(0.08)[0.079]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::231:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4dL4hz25wnz3xTK I've got a 14.3-STABLE / 15-STABLE (behavior under both) with a wireguard VPN running and assigned to the second routing table. I've noticed outbound packets being blocked at the firewall (also 14.3-STABLE/15.0-STABLE) with the VPN endpoint address (the private IP, not public). There is only one application running that uses the VPN, and it is started by "setfib 1". Most traffic does go to through the wireguard interface; it's only the RST packets being sent out of the ethernet interface, and it looks like it is most of them. I've tested this on two machines and find the same behavior on both. The RST packet going out the wrong interface on the server (on igc0): 15:49:23.229671 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.22.x.x > y.y.y.y: Flags [R], cksum 0x1bda (correct), seq 3561974863, win 0, length 0 And blocked at the firewall: rule 26/0(match): block out on sfp0: 10.22.x.x.57653 > y.y.y.y.16459: Flags [R], seq 2027176873, win 0, length 0 Routing table 0: Internet: Destination Gateway Flags Netif Expire default 10.0.0.254 UGS igc0 10.0.0.0/24 link#1 U igc0 10.0.0.1 link#3 UHS lo0 10.22.x.0/24 link#10 U wg0 10.22.x.x link#3 UHS lo0 127.0.0.1 link#3 UH lo0 Routing tables (fib: 1) Internet: Destination Gateway Flags Netif Expire default link#10 US wg0 127.0.0.1 link#3 UH lo0 PF is disabled on the server, and there is no obvious "cross pollution" of routing tables. Are there any socket operations or flags that the application could be using that would result in a packet going through routing table 0 instead of the one specified with setfib? Is there some obvious solution to this I'm missing, or should I file a PR? Thanks