Re: tap interface forcing a permanent ARP association

On Thu, Nov 30, 2023 at 1:30 AM Paul Procacci <pprocacci@gmail.com> wrote:

>
>
> On Wed, Nov 29, 2023 at 10:35 PM Olivier <Olivier.Nicole@cs.ait.ac.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="tap0 bridge0"
>> ifconfig_bridge0="addm vmx0 addm tap0"
>> ifconfig_tap0="UP"
>> openvpn_enable="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=UP"
>> 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 imagine
> 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
-- 
__________________

:(){ :|:& };: