:: Re: [DNG] Can't ping outside of my …
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Axy
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] Can't ping outside of my network after having configured a tun tap device
This won't work while default dev tap0 is in. Your routing table should
have the only default route, via your wlx adapter. It looks like qemu vm
networking is on your way (and all the rest network managers maybe), but
I can't help with its settings, sorry.

Axy


On 10/6/23 22:21, Mario Marietto via Dng wrote:
> ---> 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 <http://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 <http://169.254.0.0/16> dev tap0 proto kernel scope
> link src 169.254.192.128
> 192.168.1.0/24 <http://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 <http://169.254.0.0/16> dev tap0 proto kernel scope
> link src 169.254.192.128
> 192.168.1.0/24 <http://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 <http://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 <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

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