:: [DNG] Fwd: Can't ping outside of my…
Top Page
Delete this message
Reply to this message
Author: Mario Marietto
Date:  
To: Mario Marietto via Dng
Subject: [DNG] Fwd: Can't ping outside of my network after having configured a tun tap device
I think I got it working in a dirty way. This is what I did :

1. Shut down libvirt
2. Create a bridge br1 manually without any slaves ( ip link add name
br1 type bridge)
3. Added "allow all" to that bridge helper file (bridge.conf, you had
that file somewhere below /usr/local)
4. Started a VM with qemu only, telling it to use a bridge interface
"br1". This will create a tap interface "tap0" *which is a slave *of a
bridge "br1"
5. Right after VM start, explicitly set link br1 to "up" ( ip link set
br1 up)
6. Configured an IP address from within the VM in a new subnet (
192.168.20.2/24)
7. Configured IP address in the same subnet for br1 on KVM host (
192.168.20.1/24). No IP on the tap interface :* ip a add 192.168.20.1/24
<http://192.168.20.1/24> dev br1*
8. Configured MASQUERADING for traffic leaving through my standard home
interface on the KVM host: iptables -t nat -A POSTROUTING -o mlan0 -j
MASQUERADE
9. Enable Routing : *echo* 1 > /proc/sys/net/ipv4/ip_forward


That's it. The VM could ping everything,but another step is necessary :

After that the VM has been started,I should do : ip a fl dev tap0

This is a dirty workaround that I don't like too much,but it removes
the fake IP address
169.254.89.8 from the TAP0 and in this way I can ping the world while
I'm using the VM.


Anyway every time I start a new VM,a new (and the same) fake ip
[169.254.35.253] is assigned to the TAP interface and I should delete it
everytime. That's annoying. Do you know why tap0 interferes with the
correct working of the network ? Maybe what's wrong is the qemu parameter
that manages the network :

I tried to add a script directly between the qemu parameters like this :

- net nic,model=virtio,macaddr=52:54:00:00:00:01 -net
bridge,br=br1,script=*"/bin/ip
a fl dev tap0"* \

but it didn't work : the error is "invalid parameter script".

Instead of deleting its IP address,can't it be routed correctly in some way
?


---------- Forwarded message ---------
From: Axy via Dng <dng@???>
Date: Sat, Oct 7, 2023 at 6:04 AM
Subject: Re: [DNG] Can't ping outside of my network after having configured
a tun tap device
To: <dng@???>


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

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


--
Mario.