From nobody Thu Nov 30 06:38:05 2023 X-Original-To: questions@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 4SgmjQ2cfjz52vgK for ; Thu, 30 Nov 2023 06:38:18 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SgmjP3vDqz4XKB for ; Thu, 30 Nov 2023 06:38:17 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=nigZ1fsK; spf=pass (mx1.freebsd.org: domain of pprocacci@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=pprocacci@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-54b0073d50fso440838a12.2 for ; Wed, 29 Nov 2023 22:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701326296; x=1701931096; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OhfyUny1vG6UiD+nVlH0CVFhzGTrR2yCotSpE5xwLRg=; b=nigZ1fsK+KLPxoPszpYwCK3F7Z+8r4rUz93NLbQWy3s6xKu1gGF7CoLi6+/XKTvhsx WicgK9StefWOfPDyV/BPTx0LXOkk02y4clZ5couSjVa0IRx6CGDNZdX2cys+uzB2EVOn UquYHCVBKykgXGeckOzzKUHwdEduWumGkRbWq56mhsKtdCgdyMldC/je/v3RkSl6AhcW OCjpZRRoyu17SBLCIGvBfcPYE51Naf9tUBtI5hjUQL5+M/iep8w6AV3KfPorD5w/tUIY q4ivohXRGJs/cWk571c/ZrV0fIqP9dWYJRwZTLxOsVJ5F3uegod3Mn/IqdrWddlB1oJe Pzpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701326296; x=1701931096; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OhfyUny1vG6UiD+nVlH0CVFhzGTrR2yCotSpE5xwLRg=; b=vSOPR1Cr72y0W/gjGzCd70SfAOkbNjWyv0Ol6W7MbEOzpc0qLrhuyf2k3Fzj3ZphF+ SlJ1M4J3zHKIDwARLDyuYff4v786AeIKO9y6NxYAs6yHYjIIueuIy0MFzhtyBUohnFF8 /cwJOXO/csBM/E3AhTxH2GXxYNnb7OrRA7JZ8xHj33QZw/zcOkvBCfLDACl/foR86+4W z8zITBnhKQ1KncD5oBpPpnzPL3KsRzPFqx9+gDaa//tZY/a5OiibJ3cgmp1UxeyyBI/H eX9Nx+SeYto0YPDUlzYULhQwSXJ4HUPPRZK3LA5H1+Ei+jL5pKBeQIazi0yofzXXZoA+ FpqQ== X-Gm-Message-State: AOJu0Yz8vYo2nTbgQQyAauBdMlIbH6dBWVTRbivuFpikKSXguUets3xB OsLyAjcxBou4zYysSWtSas5TV6+MbM+anStp0xd8OeLVoQ== X-Google-Smtp-Source: AGHT+IGBLel0+9DD54jGeT1w8v8w7WKQmWY+eAtMkK36BGwkzi1DdkDoXkLtST6pCnfJdJGr5qNOzkcnSePYZZTaIys= X-Received: by 2002:a17:906:24c:b0:a18:5d42:991e with SMTP id 12-20020a170906024c00b00a185d42991emr872277ejl.11.1701326295750; Wed, 29 Nov 2023 22:38:15 -0800 (PST) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Paul Procacci Date: Thu, 30 Nov 2023 01:38:05 -0500 Message-ID: Subject: Re: tap interface forcing a permanent ARP association To: Olivier Cc: questions@freebsd.org Content-Type: multipart/alternative; boundary="000000000000815b4a060b58e591" X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.957]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[questions@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4SgmjP3vDqz4XKB X-Spamd-Bar: --- --000000000000815b4a060b58e591 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 30, 2023 at 1:30=E2=80=AFAM Paul Procacci = wrote: > > > On Wed, Nov 29, 2023 at 10:35=E2=80=AFPM Olivier > wrote: > >> Hi, >> >> I have an OpenVPN server running on FreeBSD (13.2-p5). I have included >> the following in /etc/rc.conf: >> >> cloned_interfaces=3D"tap0 bridge0" >> ifconfig_bridge0=3D"addm vmx0 addm tap0" >> ifconfig_tap0=3D"UP" >> openvpn_enable=3D"YES" >> >> And it works fine, except that ip maps the MAC address of tap0 to the IP >> of my web server (on another machine), and the mapping is "permament": >> >> www.cs.ait.ac.th (10.41.170.42) at aa:bb:cc:dd:ee:ff on tap0 permanent >> [ethernet] >> >> That has two adverse effects: >> - any VPN client cannot access my web server as they would get a wrong >> MAC address; >> - the VPN server will sometime reply to an ARP request on my LAN, >> providing an obviously wrong answer. >> >> Poking around, I found out that it was due to the "ifconfig_tap0=3DUP" >> line. Further more, that line is not needed for OpenVPN to start >> properly; so I have disabled it. >> >> But I would like to understand why turning up the tap interface causes >> it to update the ARP table. >> >> Best regards, >> >> Olivier >> >> -- >> >> > If I'm being honest, what you're saying sounds really strange. > NIC vendors have prefixes assigned to them for their MAC usage and the > chances of collision between two machines especially since the local nic = in > question is a tap is an absolute fat 0 chance. > -- That is, unless somewhere someone is doing something they shouldn't, > or perhaps the entire picture wasn't provided and information is missing. > > In regards to the actual question .... > > Turning up _any_ interface means layers 1 and 2 of an OSI model at a bare > minimum come online/available. > With that, MAC addresses for the device in question get presented on the > port, whether physical or virtual, and are usually within a single > broadcast domain. > > With that knowledge, I'd think it's reasonable to imagine a world where a > given machine would prefer its own mac (permanent) over one learned from = a > connected device. > My last sentence is pure speculation, but surely a good one as I'd imagin= e > nearly all operating systems behave the same way. > > ~Paul > > > -- > __________________ > > :(){ :|:& };: > ... and before you reply (just thought of something else), if we're talking virtual machines here, some that have been cloned from a base image or something along those lines, go ahead and check the following sysctl to ensure it's unique between machines: kern.hostuuid I did a quick search in the tap source code and it generates it's MAC with the function iflib_gen_mac which in turn generates a mac starting with 58-9C-FC and ending with the first 3 byts of the md5 of the hostuuid-ifname0. ~Paul --=20 __________________ :(){ :|:& };: --000000000000815b4a060b58e591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 30, 2023 at 1:30=E2= =80=AFAM Paul Procacci <pprocacci= @gmail.com> wrote:

=
On Wed= , Nov 29, 2023 at 10:35=E2=80=AFPM Olivier <Olivier.Nicole@cs.ait.ac.th> wr= ote:
Hi,

I have an OpenVPN server running on FreeBSD (13.2-p5). I have included
the following in /etc/rc.conf:

cloned_interfaces=3D"tap0 bridge0"
ifconfig_bridge0=3D"addm vmx0 addm tap0"
ifconfig_tap0=3D"UP"
openvpn_enable=3D"YES"

And it works fine, except that ip maps the MAC address of tap0 to the IP of my web server (on another machine), and the mapping is "permament&q= uot;:

ww= w.cs.ait.ac.th (10.41.170.42) at aa:bb:cc:dd:ee:ff on tap0 permanent [e= thernet]

That has two adverse effects:
- any VPN client cannot access my web server as they would get a wrong
MAC address;
- the VPN server will sometime reply to an ARP request on my LAN,
providing an obviously wrong answer.

Poking around, I found out that it was due to the "ifconfig_tap0=3DUP&= quot;
line. Further more, that line is not needed for OpenVPN to start
properly; so I have disabled it.

But I would like to understand why turning up the tap interface causes
it to update the ARP table.

Best regards,

Olivier

--


If I'm being honest, what yo= u're saying sounds really strange.
NIC vendors have prefixes assigne= d to them for their MAC usage and the chances of collision between two mach= ines especially since the local nic in question is a tap is an absolute fat= 0 chance.
=C2=A0 -- That is, unless somewhere someone is doing somethin= g they shouldn't, or perhaps the entire picture wasn't provided and= information is missing.

In regards to the actual questio= n ....

Turning up _any_ interface means layers 1 and 2 of an O= SI model at a bare minimum come online/available.
With that, MAC a= ddresses for the device in question=20 get presented on the port, whether physical or virtual, and are usually wi= thin a single broadcast domain.

With that knowledge, I= 9;d think it's reasonable to imagine a world where a given machine woul= d prefer its own mac (permanent) over one learned from a connected device.<= br>
My last sentence is pure speculation, but surely a good one a= s I'd imagine nearly all operating systems behave the same way.

~Paul


--
= __________________

:(){ :|:& };:

... and before you reply (just t= hought of something else), if we're talking virtual machines here, some= that have been cloned from a base image or something along those lines,=C2= =A0 go ahead and check the=20 following sysctl to ensure it's unique between machines:

k= ern.hostuuid

I did a quick search in the tap source code= and it generates it's MAC with the function iflib_gen_mac which in tur= n generates a mac starting with=20 58-9C-FC and ending with the first 3 byts of the md5 of the hostuuid-ifname0.
~Paul
-- <= /span>
__________________
=
:(){ :|:& };:
--000000000000815b4a060b58e591--