Date: Thu, 30 Nov 2023 01:38:05 -0500 From: Paul Procacci <pprocacci@gmail.com> To: Olivier <Olivier.Nicole@cs.ait.ac.th> Cc: questions@freebsd.org Subject: Re: tap interface forcing a permanent ARP association Message-ID: <CAFbbPuhZqwCtmvbV%2B%2B%2BjhKuSq8RV4YDLc=5pRJ0sNJpk6_Fmbw@mail.gmail.com> In-Reply-To: <CAFbbPui4HpP67DD%2BKDX%2Bnn%2BXF8%2B4Z71bZeG3-M0hMxf15F7qRg@mail.gmail.com> References: <wu7jzpzc3rw.fsf@banyan.cs.ait.ac.th> <CAFbbPui4HpP67DD%2BKDX%2Bnn%2BXF8%2B4Z71bZeG3-M0hMxf15F7qRg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <pprocacci@gmail.com>=
wrote:
>
>
> On Wed, Nov 29, 2023 at 10:35=E2=80=AFPM Olivier <Olivier.Nicole@cs.ait.a=
c.th>
> 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
<div dir=3D"ltr"><div><div dir=3D"ltr"><br></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 30, 2023 at 1:30=E2=
=80=AFAM Paul Procacci <<a href=3D"mailto:pprocacci@gmail.com">pprocacci=
@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><div><div><div><div dir=3D"ltr"><br></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed=
, Nov 29, 2023 at 10:35=E2=80=AFPM Olivier <<a href=3D"mailto:Olivier.Ni=
cole@cs.ait.ac.th" target=3D"_blank">Olivier.Nicole@cs.ait.ac.th</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I have an OpenVPN server running on FreeBSD (13.2-p5). I have included<br>
the following in /etc/rc.conf:<br>
<br>
cloned_interfaces=3D"tap0 bridge0"<br>
ifconfig_bridge0=3D"addm vmx0 addm tap0"<br>
ifconfig_tap0=3D"UP"<br>
openvpn_enable=3D"YES"<br>
<br>
And it works fine, except that ip maps the MAC address of tap0 to the IP<br=
>
of my web server (on another machine), and the mapping is "permament&q=
uot;:<br>
<br>
<a href=3D"http://www.cs.ait.ac.th" rel=3D"noreferrer" target=3D"_blank">ww=
w.cs.ait.ac.th</a> (10.41.170.42) at aa:bb:cc:dd:ee:ff on tap0 permanent [e=
thernet]<br>
<br>
That has two adverse effects:<br>
- any VPN client cannot access my web server as they would get a wrong<br>
MAC address;<br>
- the VPN server will sometime reply to an ARP request on my LAN,<br>
providing an obviously wrong answer.<br>
<br>
Poking around, I found out that it was due to the "ifconfig_tap0=3DUP&=
quot;<br>
line. Further more, that line is not needed for OpenVPN to start<br>
properly; so I have disabled it.<br>
<br>
But I would like to understand why turning up the tap interface causes<br>
it to update the ARP table.<br>
<br>
Best regards,<br>
<br>
Olivier<br>
<br>
-- <br>
<br>
</blockquote></div><br clear=3D"all"></div>If I'm being honest, what yo=
u're saying sounds really strange.<br>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.<br>=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.<br><br></div><div>In regards to the actual questio=
n ....<br><br></div>Turning up _any_ interface means layers 1 and 2 of an O=
SI model at a bare minimum come online/available.<br></div>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.<br><br></div><div>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></div><div>My last sentence is pure speculation, but surely a good one a=
s I'd imagine nearly all operating systems behave the same way.<br></di=
v><div><br></div>~Paul<br><div><div><br><br><div><div><span class=3D"gmail_=
signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">=
__________________<br><br>:(){ :|:& };:</div></div></div></div></div></=
div>
</blockquote></div><br clear=3D"all"></div>... 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:<br><br><div>k=
ern.hostuuid <br></div><div><br>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.<br><br=
></div><div>~Paul<br></div><div><span class=3D"gmail_signature_prefix">-- <=
/span><br><div dir=3D"ltr" class=3D"gmail_signature">__________________<br>=
<br>:(){ :|:& };:</div></div></div>
--000000000000815b4a060b58e591--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFbbPuhZqwCtmvbV%2B%2B%2BjhKuSq8RV4YDLc=5pRJ0sNJpk6_Fmbw>