>     Okay, let me try to explain (Friday is the excuse)

>     I know nothing about qemu-kvm-libvirt, but at a glance it should
>     facilitate networking a lot, but I don't know how. Let's turn to the
>     basics instead.

>     If you chose tap, which afaik is a way to handle ethernet frames in
>     userspace, the handler could be any userspace process (e.g.
>     qemu-kvm-libvirt). So your tap0 is actually one end of the wire. The
>     opposite end is somewhere in qemu-kvm-libvirt (again, I know nothing
>     about it, I'm an LXC user) and to reach that end you need the
>     following
>     route on your host system:

>     ip route add 192.168.99.0/24 <http://192.168.99.0/24> dev tap0

>     So if you ping some IP address in 192.168.99.0networkfrom the host
>     system, packets will be routed to your virtualized system and if
>     it has
>     that IP address it will respond. Of course that system should have
>     the
>     default route back to 192.168.99.1

>     Same in LXC, where we use veth, which is a pair of linked interfaces:
>     one is on the host system, another is assigned to the container .

>     You do not need a bridge interface.

>     Once again:

>     You do not need a bridge interface. In this configuration packets
>     come
>     from a virtualized system and go through NAT to mlan0. Your NAT rule

>     iptables -t nat -A POSTROUTING -o mlan0 -j MASQUERADE

>     looks correct.

>     The only reason you can't ping 8.8.8.8 even from the host system is
>     messy routes. Assuming your mlan0 is the way to the Internet, the
>     only
>     default route should be:

>     default via 192.168.1.1 dev mlan0

>     With these ones

>     0.0.0.0 dev tap0 scope link

>     default dev tap0 scope link

>     packets will be directed to the wrong interface and embarrass your
>     virtualized system. Drop these routes.

>     You would need a bridge if you wanted your host system and
>     virtualized
>     system to be on the same ethernet network (domain, segment,...)
>     However,
>     bear in mind: wifi interfaces in client mode cannot be bridged. In
>     access point mode that does work, but does not work in client
>     mode. Only
>     wired interfaces can be freely bridged.

>     Axy

>     On 10/6/23 13:37, Mario Marietto via Dng wrote:
>     > As long as I don't have any routing rules in my home network
>     (static
>     > or done by routing protocols such as OSPF or RIP), my KVM server
>     will
>     > be the only host in my network that knows how to reach
>     192.168.20.0/24 <http://192.168.20.0/24>
>     > <http://192.168.20.0/24> (because it has 192.168.20.1 itself). That
>     > means, my VMs will not be able to reach any other network. The
>     > simplest approach to get this to work is to do NAT for /outgoing/
>     > traffic. Now this kind of NAT is an SNAT, not a DNAT. While classic
>     > SNAT is a one-to-one-mapping, MASQUERADE simply means "replace
>     every
>     > source IP with the IP on the outgoing interface".
>     >
>     > On Fri, Oct 6, 2023 at 8:51 AM Mario Marietto
>     <marietto2008@???>
>     > wrote:

>     >
>     >     Thanks.

>     >
>     >     so,maybe this is the solution :

>     >
>     >     |# iptables -t nat -A POSTROUTING -o mlan0 -j DNAT # ip
>     tuntap add
>     >     tap0 mode tap # ip link set dev tap0 up # ifconfig tap0
>     > 192.168.99.1/24 <http://192.168.99.1/24>
>     <http://192.168.99.1/24> # echo 1 >
>     >     /proc/sys/net/ipv4/ip_forward|

>     >

>     >
>     >     iptables v1.8.9 (nf_tables): DNAT: option "--to-destination"
>     must
>     >     be specified

>     >
>     >     What could be the destination ? thanks.

>     >
>     >     On Fri, Oct 6, 2023 at 1:44 AM Gregory Nowak
>     <greg@???> wrote:

>     >
>     >         On Thu, Oct 05, 2023 at 02:20:47PM +0200, Mario Marietto via
>     >         Dng wrote:
>     >         > I'm trying to set up a bridge on Linux Devuan 5 (host os)
>     >         with the
>     >         > goal to give the connectivity to FreeBSD 13.2,that I have
>     >         virtualized
>     >         > with qemu-kvm-libvirt.

>     >
>     >         If you're trying to setup a bridge, then you're going
>     about it the
>     >         wrong way.. You'd set that up in /etc/network/interfaces, or
>     >         in a file
>     >         under /etc/network/interfaces.d where you bridge your
>     mlan0 to
>     >         your
>     >         tap0. This is more involved when using wifi, but it can be
>     >         done. See
>     >         man interfaces, the bridge-utils package, and the
>     wpasupplicant
>     >         package. You mentioned
>     >         you're using network manager. If so, then you will probably
>     >         want to
>     >         dump network manager if you go this route.

>     >
>     >         > on Devuan I did :

>     >         >
>     >         > # iptables -t nat -A POSTROUTING -o mlan0 -j MASQUERADE

>     >
>     >         If you want to keep going the way you are, then I think you
>     >         want the
>     >         DNAT target, not MASQUERADE.

>     >
>     >         Greg

>     >

>     >
>     >         --
>     >         web site: http://www.gregn.net
>     >         gpg public key: http://www.gregn.net/pubkey.asc
>     >         skype: gregn1
>     >         (authorization required, add me to your contacts list first)
>     >         If we haven't been in touch before, e-mail me before
>     adding me
>     >         to your contacts.

>     >
>     >         --
>     >         Free domains: http://www.eu.org/ or mail dns-manager@???

>     >

>     >

>     >
>     >     --
>     >     Mario.

>     >

>     >

>     >
>     > --
>     > Mario.

>     >
>     > _______________________________________________
>     > Dng mailing list
>     > Dng@???
>     > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>     _______________________________________________
>     Dng mailing list
>     Dng@???
>     https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng