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 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> (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> # 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
::
Re: [DNG] Can't ping outside of my …
