From nobody Tue Oct 10 17:26:22 2023 X-Original-To: freebsd-current@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 4S4jWT05YMz4x4KC for ; Tue, 10 Oct 2023 17:27:01 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4S4jWR6cYrz3Crj for ; Tue, 10 Oct 2023 17:26:59 +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=YGc+dEVc; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (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 smtp5.goneo.de (Postfix) with ESMTPS id 6C2E0240D23 for ; Tue, 10 Oct 2023 19:26:52 +0200 (CEST) Received: from hub1.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 hub1.goneo.de (Postfix) with ESMTPS id CBA0A240D8E for ; Tue, 10 Oct 2023 19:26:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1696958810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=830Y6gUT4AuZAZ+7mwXEQ8mXQLcnYnE9jikVq0A89Aw=; b=YGc+dEVcCNUm+7O/G0jxysu2C841GTu8j0QHzYhCpbnt5StEz+Oqnpearl9dU8U6m41BfN V8eI5XOchIkiPhtpiDUuBVu9UlR5o1f+wrL78IOEYHvhqSbEBy5UkvLF75ACAQlLjMO+SE LvJJFnm4BvpOV6GKEScKjcCi/jqD4MV0hn7KkRCfH1wPxCqdCUvDYq/hTvF/OTqr3hDwid BHVRWdEl99KztcT7L58reUWSttiRoafclC06KV/1BhAyiqYKlsaHXDL1AwO+3t5ThJ64VK pmfD4cUktCOpXNWaNu2eHq5vxlgBeEx+nGowTRiar4bnJMd6t60XQLuX0m/GTw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-055-111-189.78.55.pool.telefonica.de [78.55.111.189]) (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 hub1.goneo.de (Postfix) with ESMTPSA id 4115724099A for ; Tue, 10 Oct 2023 19:26:50 +0200 (CEST) Date: Tue, 10 Oct 2023 19:26:22 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: epair/vbridge: no IPv6 traffic egress until first IPv6 packet flows in Message-ID: <20231010192649.54272d49@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 74e2aa X-Rspamd-UID: 97142c X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.22 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.925]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; BLOCKLISTDE_FAIL(0.00)[78.55.111.189:server fail,2001:1640:5::8:52:server fail,85.220.129.60:server fail]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4S4jWR6cYrz3Crj Hello, at first: observation is below, marked [OBSERVATION]. Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef: Mon Oct 9 14:00:42 CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface igb0 (I350-T2 two port Gigabit Network Connection ) is member of that bridge and so a couple of epair(4) devices belonging to a couple of jails. IP filter is ipfw, each jail does have profile "WORKSTATION" configured and enabled, so the host itself. On those hosts I use the standard rc facility. Additionally, following MIB knobs are set to the following values: net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 and net.link.ether.inet.allow_multicast: 0 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.ether.inet.max_log_per_second: 1 net.link.ether.inet.maxhold: 16 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.arp.log_level: 6 net.link.ether.ipfw: 0 On epairs as well as on the main hosts igb0 NIC, both IPv4 and IPv6 are configured, IPv6 uses ULA and setup doesn't has anything fancy. Pinging and connecting to hosts "outside" the box of the host in question (all FreeBSD CURRENT/14-STABLE) is possible without ANY(!) restriction or something nonregular. [OBSERVATION] JAILs can ping any(!) IPv4 host in the net, the main-jail-bearing-host (main-host) itself or any host on the configured bridge() (important: jail -> main-host). JAILs can ping IPv6 any host on the bridge() or in the net or in the internet, BUT NOT the main-host (igb0-owner). NO IPv6 related service FROM jail TOWARD main-host is possible, it is all blocked (and I do not know what blocks or how ...). Disbaling IPFW via "ipfw disable firewall" on all jails and main-host doesn't have any effect in this state. BUT: if the main-host IPv6 pings a jail on that bridge (packet flowing into (the) jail/ingress from jail's perspective), the jail itself suddenly is then able to ping or do network traffic in IPv6! Other jails remain dead that way for IPv6 until I ping them. I haven't or I'm unable to check(ed) why ipv6-icmp is mysteriously "opening" the connection. SSH'ing via IPv6/TCPv6 from the main-host into a jail (tcp/22) works also perfectly and works as the "openener" - a stuck ping -6 towards the main-host then immediately starts flowing. I remember that such a similar problem occured somewhere around FreeBSD 10/11 and the problem vanished somehow in the vain of development/patching. Even disabling IPFW on all entities or switching to profile "open" doesn't help. Some services, like LDAP, nslcd do not work from jails if the jail remains in the initial state. That troubles me. Pinging via IPv6 icmp the jail seems to loosen all restraints, LDAP works, ping works, everything on IPv6 is normal as expected. But the JAIL has to be pinged from the outside first! As stated, I'm out of ideas here and what troubles me most is the fact even LDAP doesn't work until the jail is pinged via icmp6 first time.After this "init", everything is normal. IPv4 seems to be unharmed ... Thanks for your patience and reading, Kind regards oh -- O. Hartmann