From nobody Sun Jan 14 11:49:05 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 4TCYTv10crz57kNq; Sun, 14 Jan 2024 11:49:39 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TCYTt0qkRz4xDk; Sun, 14 Jan 2024 11:49:38 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=AMxR2TM0; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id E696F24082D; Sun, 14 Jan 2024 12:49:34 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 52988240486; Sun, 14 Jan 2024 12:49:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1705232973; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HOnvODjHjpCDhv8hvItAj2aytdze9QiSyeAXXrGz7dQ=; b=AMxR2TM0EwIgThgpPkk6sWIGrD+hQsm3B+hdX76u4l71uUxplPRPgNWpgt2dAcbXRRqnuk 2iEtTWfik4TJMzR7nQgiiqmZMd3ap2E2z37g9sKb1pBR2HROunf4pKpBFDjcsmp08sNXPt Ai2oG9SUqQFoYQDcVHRX2JjJ9Aw9gnVPgNdh9/o++ctHG1bBJi6hVINPb9NgykJTdDb7VH 8RLRt1cpF6Px0CAH/d0S5nx9sbKfwvov3gGzY8/k5iU6MtYJI3HubWk7gfTIscxiSbg0ce 3CR+Iupj1mPjn7gF0FdTHe5Vgdl0IzHc5Pqd4NON/ijGyuNUopgFm/vcuJiGvQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-154-128.77.11.pool.telefonica.de [77.11.154.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 0C00724002E; Sun, 14 Jan 2024 12:49:33 +0100 (CET) Date: Sun, 14 Jan 2024 12:49:05 +0100 From: FreeBSD User To: Felix Reichenberger Cc: FreeBSD CURRENT , FreeBSD CURRENT Subject: Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6) Message-ID: <20240114124932.2db7ef36@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20240107185133.68824d89@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: a2c514 X-Rspamd-UID: 9086ea X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4TCYTt0qkRz4xDk Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024 amd64 > > > > Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP and ICMP > > (ipfw is configured via rc.conf in this case, host is listening on both protocol families > > IPv4 and IPv6). > > > > The host itself has openldap-server 2.6 as a service. The host's interface is igb0 with > > assigned ULA. JAILs (around eight jails) are sharing their vnet interfaces via a bridge > > with the same physical device as the host (igb0). After a while (the time elapsed is > > unspecific) the jail is unable to contact the host via IPv6: neither UDP, TCP nor ICMP > > sent from the JAIL is reaching the host. IPv4 is working like a charme! No problems there. > > > > When pinging the Jail from the main host via ping -6, the jail is responding! After the > > first ping -6, the jail now is able to ping -6 the main host. > > > > After a fresh reboot, the problem is not present and occurs after a while and it seems to > > happen first to very active jails. > > > > Kind regards, > > > > oh > > > > > > -- > > O. Hartmann > > > > Hello, > > This behavior might be caused by IPFW blocking some IPv6 neighbor discovery/advertisement > messages. > After some time, the link layer addresses of the IPv6 neighbors in the NDP cache may expire, > making the associated IPv6 addresses inaccessible. > Do your IPFW rules allow ICMPv6 messages to and from IPv6 multicast addresses? > > Regards. > Thank you for responding. Thank you for his valuable hint! The jail(s) itself/themselfes as well as the host use the regular ipfw rc setup script as provided with the base system, adding simply those ports open which provide services - a plain and simple approach. Checking the jails on the host in question (jails are contacting OpenLDAP server on host, OpenLDAP server configured for test purposes to listen only on IPv6) leaves me with inconclusive results. Assuming a jail, called host-git, and a host, master. Deleting the NDP entries aon hostgit via "ndp -c" leaves me with the initial reported issue here, the solution is to ping the host-git first from host-master to "magically open" the IPv6 connection. After that, ldapsearch or any other IPv6 connections originating on the host-git work again. That seems odd. jails are vnet. Jails reside on a bridgeXX interface, sharing the physical NIC of the master host. Just for the record. I use a similar setup on a XigmaNAS host (13.2-RELEASE-p8), also with active IPFW on the master host's side as well as IPFW enabled on the Jail's side. Difference to the above mentioned setup: The jail is located on a different host, contacting master-host via a switched network. Regards, oh -- O. Hartmann