From nobody Thu Nov 30 06:30:04 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 4SgmX92nC5z52vN6 for ; Thu, 30 Nov 2023 06:30:17 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 4SgmX90VB2z4Vfg for ; Thu, 30 Nov 2023 06:30:17 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a1882023bbfso37852666b.3 for ; Wed, 29 Nov 2023 22:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701325815; x=1701930615; 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=S5QTac4UUu8cKhHcimPrYBo2WcSx/UVYZx1Yg3Pm3aM=; b=dr3VocRYszntB/2wMwwaDMQ0rJpS17LusKpE6QdOzGZLVQjl0YA47spTDM05IYFeC8 WRXgGROgDO5ocv+vSxQCLLbSM2MOTuqWFbBpNwnrt5dO0QGNKJPdtKznDDvD97P2e4CZ aOXgGAwM+dK173q0LHH5+SANq+4oYnutvOk47uh1xRVyCPPMWnG/eJvIOuf+4AFB7xRq egBZODGWaqlC6w+aR925Cn5j+6f2Q7pewl7c58RwJtFHAnO3J5qSrgNQUIHoCTTdEFHn 2AnNAWuZsPt+fQOFdTl8vLIowIeVTjzoMC7JMOfLHuu3YFExqk+IL0xaJZxUGlb3d0i0 0tgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701325815; x=1701930615; 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=S5QTac4UUu8cKhHcimPrYBo2WcSx/UVYZx1Yg3Pm3aM=; b=ghhQBC65SjKeDkOiXY1P61tuZOKQ2vaTH4bfJTfTKJYM/zv/cofKAU0GYPFML7UMP3 mddHKpISMEmkxrTvI4IjYCo1yL2W47URGx30bh1egkKpp5g4fnvUv8h5RNT2GFv/o0mF 9ILkexf7XGP4ibRNwApO6WLBc1zq0sjNS7/HPWkxYz7CqyJ1w81Y1z+YMCDRAW9dRJ3j OSeXHNeIcv0o1N+cwKG98A64218JmAmhS9FaREVTStmSzQWaM4Tx+qg4Mpi6cN3htVe3 RHO+0dmgl85qooQQAm/ElnDNbR3/LOVhpVwR/w3pYE2Lt9W/MTIdUKx55V1iqrOgDUt5 wIYA== X-Gm-Message-State: AOJu0YzZrqqA9PjGnYLoSQONN5WBb5uHtTqUm1WMN+nfbkuLU9ppPal+ uBnXzo7OGlejSetsGf3caoKdeRXCoWBcoVTD2R6Qxyw9PQ== X-Google-Smtp-Source: AGHT+IFjemgEjLgiRS4aYy92m4xmllWdz+8o7PNPu9MiClgh05EiznoCkRImcjF2nn3Z+h7KtEeEeueUDPKEktVCsrI= X-Received: by 2002:a17:906:1351:b0:a18:bcf0:deff with SMTP id x17-20020a170906135100b00a18bcf0deffmr282068ejb.26.1701325814968; Wed, 29 Nov 2023 22:30:14 -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:30:04 -0500 Message-ID: Subject: Re: tap interface forcing a permanent ARP association To: Olivier Cc: questions@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d937bb060b58c892" 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: 4SgmX90VB2z4Vfg --000000000000d937bb060b58c892 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 imagine nearly all operating systems behave the same way. ~Paul --=20 __________________ :(){ :|:& };: --000000000000d937bb060b58c892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 29, 2= 023 at 10:35=E2=80=AFPM 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=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


--
= __________________

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