From nobody Mon Dec 30 16:05:44 2024 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 4YMLYY4R07z5k6xC for ; Mon, 30 Dec 2024 16:05:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 (2048 bits) client-digest SHA256) (Client CN "vps1.elischer.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YMLYX5vJ2z4nSN for ; Mon, 30 Dec 2024 16:05:52 +0000 (UTC) (envelope-from julian@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 204.109.63.16 is neither permitted nor denied by domain of julian@freebsd.org) smtp.mailfrom=julian@freebsd.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none) Received: from [192.168.20.22] (180-150-86-67.b49656.per.static.aussiebb.net [180.150.86.67]) (authenticated bits=0) by vps1.elischer.org (8.17.2/8.16.1) with ESMTPSA id 4BUG5nZg062613 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 30 Dec 2024 08:05:51 -0800 (PST) (envelope-from julian@freebsd.org) X-Authentication-Warning: vps1.elischer.org: Host 180-150-86-67.b49656.per.static.aussiebb.net [180.150.86.67] claimed to be [192.168.20.22] Message-ID: Date: Tue, 31 Dec 2024 00:05:44 +0800 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 User-Agent: Mozilla Thunderbird Subject: Re: per-FIB socket binding To: freebsd-net@freebsd.org References: <4p5o59s4-5p70-0775-1479-990o1s5po7r2@yvfgf.mnoonqbm.arg> <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <202412240506.4BO56W2p075824@donotpassgo.dyslexicfish.net> Content-Language: en-US From: Julian Elischer In-Reply-To: <202412240506.4BO56W2p075824@donotpassgo.dyslexicfish.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.971]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[julian]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; HAS_XAW(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4YMLYX5vJ2z4nSN X-Spamd-Bar: -- On 12/24/24 1:06 PM, Jamie Landeg-Jones wrote: > Paul Vixie wrote: > >> i've been thinking along these lines for a few years now, since my vm server is multi-fib. >> each interface has a fib, mostly zero. for incoming TCP SYNs, i'd like to carry that fib# into >> the resulting PCB so that that fib's routing table and especially its default route will be >> used for that connection. yes, i can do that with ipfw, and am in fact doing so now. >> however, that's crocky. i think defaulting to the interface FIB for connections created and >> maintained by the kernel should always happen -- not opt-in, not opt-out, just always. is >> it worth me sending a patch that does this or would it be considered controversial? > > I like that. I isolate 5 seperate networks by assigning a fib to each interface, and was > initially surprised that I had to jump through ipfw hoops to get it to work properly, in > fact at the end of my ipfw rules for these interfaces, just to guarantee no leaking, > I have this, out of kludgy desperation! : > > 05111 deny log ip from any to any fib 1 not via em1 > 05112 deny log ip from any to any fib 2 not via em2 > 05113 deny log ip from any to any fib 3 not via em3 > 05114 deny log ip from any to any fib 4 not via em4 > 05115 deny log ip from any to any fib 5 not via em5 > > So, yes, I agree that it's crocky, and your proposal is how I originally expected it to > work, and indeed, I can so no reason for it not to work that way, but am prepared to > be enlightened if anyone else has an opinion on this. > I think I made it not act that way by default when I added fibs was to keep compatibility with old code. You could add a sysctl that makes it default behaviour or not. I think the suggested patch is probably the right way to go.. for TCP anyhow, UDP is another question. You would need to allow the receiving socket to report the FIB (do I already?) of the receiving interface and use it for the response. > Jamie >