:: Re: [DNG] Can't ping outside of my …
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Mario Marietto
Fecha:  
Cc: dng
Asunto: Re: [DNG] Can't ping outside of my network after having configured a tun tap device
---> The only reason you can't ping 8.8.8.8 even from the host system is
messy routes

I realized that I can ping 8.8.8 from the host os,but only if the guest os
(freebsd) does not start. Before to start it,I have the following ip route
situation :

# iptables -t nat -A POSTROUTING -o wlx98ded00b7106 -j MASQUERADE

# ip route
default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
metric 600
192.168.1.0/24 dev wlx98ded00b7106 proto kernel scope link src 192.168.1.6
metric 600

(I have changed wi-fi adapter,now I'm using a realtek)

when the freebsd vm starts,the route situation change like this one :

# ip route

0.0.0.0 dev tap0 scope link
default dev tap0 scope link
default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
metric 600
169.254.0.0/16 dev tap0 proto kernel scope link src 169.254.192.128
192.168.1.0/24 dev wlx98ded00b7106 proto kernel scope link src 192.168.1.6
metric 600

Now what should I do ? following your suggestion,I have removed these
routes :

ip route del default dev tap0 scope link
ip route del 0.0.0.0 dev tap0 scope link

Since I haven't created any tap0,the first one hasn't been deleted,but the
second one has. Now this is the situation :

# ip route

default dev tap0 scope link
default via 192.168.1.1 dev wlx98ded00b7106 proto dhcp src 192.168.1.6
metric 600
169.254.0.0/16 dev tap0 proto kernel scope link src 169.254.192.128
192.168.1.0/24 dev wlx98ded00b7106 proto kernel scope link src 192.168.1.6
metric 600

the result is that I can't ping google.com inside the vm and even on the
host os. So,I presume that I should create the tap0 interface if I want to
delete it later.

On Fri, Oct 6, 2023 at 7:03 PM Axy via Dng <dng@???> wrote:

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>



--
Mario.