Re: tap interface forcing a permanent ARP association

On Thu, Nov 30, 2023 at 11:20 PM Olivier <Olivier.Nicole@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 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.
>
> 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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=80000<LINKSTATE>
>         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=29<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
> 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=8803<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=80000<LINKSTATE>
>         ether 58:9c:fc:10:a4:65
>         groups: tap
>         media: Ethernet autoselect
>         status: no carrier
>         nd6 options=29<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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
vs
tap0: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST>

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

-- 
__________________

:(){ :|:& };: