On 12/24/24 1:06 PM, Jamie Landeg-Jones wrote:
Paul Vixie <p...@redbarn.org> 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
