From nobody Fri Dec 01 06:01:54 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 4ShMsC3ft4z53LQZ for ; Fri, 1 Dec 2023 06:02:07 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4ShMsB6xkHz3Z1Z for ; Fri, 1 Dec 2023 06:02:06 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-54b545ec229so1972266a12.0 for ; Thu, 30 Nov 2023 22:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701410525; x=1702015325; 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=WHfBNLhAHS8UxHU6PmX5DHPhPgLzSKEsr+rfOjXIFaM=; b=RBIrRYCPGumlXWg9xOyeWE1LR4KfqOS1cX2nc0llnYvVw1aCZhL+Mo36febNvfFvk2 8948aUWJqL1Cth51tmd9RMsYfBjXez5qHu0FWmlbgtHH1/eOSHOwplo0DcdcsjNBernd wnHEBb9Elv4d0Xsepf7HScrirfslpwSmsfXUw3W32YEZ62CBlG+lB9jZs48pKuwF5kZJ E0eRt21N9N1j4MYAsX/VJIPbmOyKnPubDj8vy5sFM2lQaeNZGND0mPPgHBOdDp/qSqX5 vTAFJGERbVqR+BmHqffxcM+YJrJyytXNymSWgiSCTLC9742HShF7gKRtQM200xm1DDXP RdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701410525; x=1702015325; 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=WHfBNLhAHS8UxHU6PmX5DHPhPgLzSKEsr+rfOjXIFaM=; b=b4MbW6dKt9acmzLQAAzdzupOryd68uh3/NsVurA6l7TCAioXCKfQbEQlWCvqNTvcbo M+Sr/OVIe9rFauXnL73G54WhxTUsIYo2hD1vEIAABUun9lg83OjVz+XbTgkGiO2QFNrJ qZuu8mg2LCDakv577hp8PXw4RonDr650G60Rak6mxlKTfxDJ9JebG0ifN7HnFEV2Nai6 3DmdIyoCb4C8ddRePNhIoUrBfymX9Io7qy+rPAxVqrvGsbW5CC0I7qxvsD4z60IIgJLd vFSxFjwbRrcvjqB4TTNmPub1jcz+vOcLzWcVWHZpJXpQ01me8a7scLUR7Cy9rTB16kzV iUjw== X-Gm-Message-State: AOJu0YxMHL/wcGvtYQHykNKdVIDzo9oyOVT2PyX5UR73YdiEaDEUqcjp Wd0vZBfxcKSDW3AKkWVPGcuv2uBKUvQGIcERuA== X-Google-Smtp-Source: AGHT+IFxPCiVNXh7Ry+bfzC+aNK+dItPPDv8zHQM1d9HwNj5NXV+U+5vpLiqAEjZRoaRGD+e9/nGSfCMlC+s0qFbZzY= X-Received: by 2002:a50:bae1:0:b0:54b:3edc:194 with SMTP id x88-20020a50bae1000000b0054b3edc0194mr346167ede.26.1701410524546; Thu, 30 Nov 2023 22:02:04 -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: Fri, 1 Dec 2023 01:01:54 -0500 Message-ID: Subject: Re: tap interface forcing a permanent ARP association To: Olivier Cc: questions@freebsd.org Content-Type: multipart/alternative; boundary="000000000000eeca69060b6c81f7" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ShMsB6xkHz3Z1Z --000000000000eeca69060b6c81f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 30, 2023 at 11:20=E2=80=AFPM Olivier wrote: > The plot thickens... > > Paul Procacci writes: > > > [1:text/plain Show] > > > > > > [2:text/html Hide Save:noname (7kB)] > > > > 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 ni= c > 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. > > I have checked that the hostuuid are different and that the MAC > addresses on both machines are different. > > I have conducted some more tests on a machine that has been created > from scratch, still FreeBSD RELEASE-13.2-p5 > > $ ifconfig tap0 create > $ ifconfig tap0 UP > ifconfig: WARNING: setting interface address without mask is deprecated, > default mask may not be correct. > $ ifconfig tap0 > tap0: flags=3D8843 metric 0 mtu 1= 500 > options=3D80000 > ether 58:9c:fc:10:a4:65 > inet 192.41.170.42 netmask 0xffffff00 broadcast 192.41.170.255 > groups: tap > media: Ethernet autoselect > status: no carrier > nd6 options=3D29 > > Does mofidy the ARP table and associates the IP of my web server to the > MAC of the interface tap0: > > $ arp -a | grep 192.41.170.42 > www.cs.ait.ac.th (192.41.170.42) at 58:9c:fc:10:a4:65 on tap0 permanent > [ethernet] > > While: > > $ ifconfig tap0 create > $ ifconfig tap0 up > $ ifconfig tap0 > tap0: flags=3D8803 metric 0 mtu 1500 > options=3D80000 > ether 58:9c:fc:10:a4:65 > groups: tap > media: Ethernet autoselect > status: no carrier > nd6 options=3D29 > > Doesn't: > > $ arp -a | grep 192.41.170.42 > $ > > Any idea is welcome. > > Best regards, > > Olivier > > The difference is shown in the flags: tap0: flags=3D8843 metric 0 mtu 150= 0 vs tap0: flags=3D8803 UP is the *administrative state* indicator, or what you have configured the NIC to do. RUNNING is the *operational state* indicator, or what the NIC has actually been able to do. UP without RUNNING means the NIC is not detecting a link. So what does this mean to me? I'd interpret this to mean the first tap0 you provided is connected to something while the second one isn't. ~Paul --=20 __________________ :(){ :|:& };: --000000000000eeca69060b6c81f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 30, 2023 at 11:20=E2=80= =AFPM Olivier <Olivier.Ni= cole@cs.ait.ac.th> wrote:
The plot thickens...

Paul Procacci <= pprocacci@gmail.com> writes:

> [1:text/plain Show]
>
>
> [2:text/html Hide Save:noname (7kB)]
>
> On Wed, Nov 29, 2023 at 10:35=E2=80=AFPM Olivier <Olivier.Nicole@cs.ait.ac.th= >
> wrote:
>
>=C2=A0 Hi,
>
>=C2=A0 I have an OpenVPN server running on FreeBSD (13.2-p5). I have in= cluded
>=C2=A0 the following in /etc/rc.conf:
>
>=C2=A0 cloned_interfaces=3D"tap0 bridge0"
>=C2=A0 ifconfig_bridge0=3D"addm vmx0 addm tap0"
>=C2=A0 ifconfig_tap0=3D"UP"
>=C2=A0 openvpn_enable=3D"YES"
>
>=C2=A0 And it works fine, except that ip maps the MAC address of tap0 t= o the IP
>=C2=A0 of my web server (on another machine), and the mapping is
>=C2=A0 "permament":
>
>=C2=A0 www.cs.ait.ac.th (10.41.170.42) at aa:bb:cc:dd:ee:ff on tap0 p= ermanent
>=C2=A0 [ethernet]
>
>=C2=A0 That has two adverse effects:
>=C2=A0 - any VPN client cannot access my web server as they would get a= wrong
>=C2=A0 MAC address;
>=C2=A0 - the VPN server will sometime reply to an ARP request on my LAN= ,
>=C2=A0 providing an obviously wrong answer.
>
>=C2=A0 Poking around, I found out that it was due to the "ifconfig= _tap0=3DUP"
>=C2=A0 line. Further more, that line is not needed for OpenVPN to start=
>=C2=A0 properly; so I have disabled it.
>
>=C2=A0 But I would like to understand why turning up the tap interface = causes
>=C2=A0 it to update the ARP table.
>
>=C2=A0 Best regards,
>
>=C2=A0 Olivier
>
>=C2=A0 --
>
> 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 n= ic in
> question is a tap is an absolute fat 0 chance.
> -- That is, unless somewhere someone is doing something they shouldn&#= 39;t, or
> perhaps the entire picture wasn't provided and information is miss= ing.

I have checked that the hostuuid are different and that the MAC
addresses on both machines are different.

I have conducted some more tests on a machine that has been created
from scratch, still FreeBSD RELEASE-13.2-p5

$ ifconfig tap0 create
$ ifconfig tap0 UP
ifconfig: WARNING: setting interface address without mask is deprecated, default mask may not be correct.
$ ifconfig tap0
tap0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 m= tu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D80000<LINKSTATE>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 58:9c:fc:10:a4:65
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 192.41.170.42 netmask 0xffffff00 broadcast= 192.41.170.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: tap
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: no carrier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>

Does mofidy the ARP table and associates the IP of my web server to the
MAC of the interface tap0:

$ arp -a | grep 192.41.170.42
ww= w.cs.ait.ac.th (192.41.170.42) at 58:9c:fc:10:a4:65 on tap0 permanent [= ethernet]

While:

$ ifconfig tap0 create
$ ifconfig tap0 up
$ ifconfig tap0
tap0: flags=3D8803<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D80000<LINKSTATE>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 58:9c:fc:10:a4:65
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: tap
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: no carrier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>

Doesn't:

$ arp -a | grep 192.41.170.42
$

Any idea is welcome.

Best regards,

Olivier



The difference is shown in the flags:

tap0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 m= tu 1500
vs
tap0: flags=3D8803<UP,BROADCAST,SIMPLEX,MULTICAST>=20

UP is the administrative state indicator, or what you have conf= igured the NIC to do.
RUNNING is the operational state indicato= r, or what the NIC has actually been able to do.

UP without RUNNING means the NIC is not detecting a link.

= So what does this mean to me?=C2=A0 I'd interpret this to mean the firs= t tap0 you provided is connected to something while the second one isn'= t.

~Paul

--
__________________

:(){ :|:& };:
--000000000000eeca69060b6c81f7--