From nobody Thu Oct 21 20:11:23 2021 X-Original-To: freebsd-stable@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 2E1CA181AE7E for ; Thu, 21 Oct 2021 20:18:27 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HZzM65BHwz4vKM for ; Thu, 21 Oct 2021 20:18:26 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 19LKI4EM019488 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Oct 2021 22:18:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with UUCP id 19LKI4vu019487; Thu, 21 Oct 2021 22:18:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 19LKDFkl038962; Thu, 21 Oct 2021 22:13:15 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 19LKBNEd038729 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Oct 2021 22:11:23 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 19LKBNXm038728; Thu, 21 Oct 2021 22:11:23 +0200 (CEST) (envelope-from peter) Date: Thu, 21 Oct 2021 22:11:23 +0200 From: Peter To: "Bjoern A. Zeeb" Cc: freebsd-stable@freebsd.org Subject: Re: IPv6 inconsistent local routing Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Thu, 21 Oct 2021 22:18:07 +0200 (CEST) X-Rspamd-Queue-Id: 4HZzM65BHwz4vKM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 20, 2021 at 10:06:00PM +0000, Bjoern A. Zeeb wrote: ! > You might say, it does not usually make sense to route traffic local-to- ! > local over an IPadress of an outbound interface. But actually this ! > is common practice in e.g. failover scenarios, where you don't know ! > in the app configs if your address is currently local or not - you just ! > know it carries the service. !=20 !=20 ! There used to be: !=20 ! $ sysctl -d net.link.ether.inet.useloopback net.inet6.icmp6.nd6_useloopba= ck ! net.link.ether.inet.useloopback: Use the loopback interface for local ! traffic ! net.inet6.icmp6.nd6_useloopback: !=20 ! which defined this bahviour. !=20 ! These were removed in/after the FreeBSD 10 times I think? ! I=E2=80=99d start looking from there. Hi, thank you, yeah I found these. While pointing someway into that rabbithole, it is actually a dead end at first: because, these options influence the routing table, and they are now default-ON anyway. Also, in my case, the routing table is correctly populated with lo0, so this is not the problem. And, the routing table only considers OUTgoing packets, and as we can see in my message above, my OUTgoing packets are all fine and go via lo0. It is the INcoming path that create this problem. Glancing further thru the code, I find there is a "m_pkthdr.rcvif" variable from which ipfw gets the incoming-interface info. But then that variable is spread all over the whole networking code and gets used everywhere. So unless one does already dwell in the networking code and kernel debugger, this will be extensive labour to figure out.=20 But, I just found, the other way is just as ugly: when I move my stuff to work via localhost, I need, among other things, also new kerberos principals, because these then must read e.g. "postgres/localhost", and must provide the correct principal to all concerned places. It's alot of effort, and it's the wrong direction. Normally, people thow their lamp-stack (or whatever) onto one machine, configure it all as localhost, and everything works, and nothing is modular and nothing is extensible. And then when they notice there is a problem they have no clue and pay a lot of money for containers. I started the other way round, always and only use the external interface names (and don't mix these with the hostname, the hostname is something entirely different and only relevant for mail, if at all), configure everything onto these names, and then everything works =66rom everywhere right from the beginning. Except when ipfw gets these creepily mixed interface tags. Ob-rant. Thanks for listening. Cheerio, PMc