Could you show output of "ip -a" and "ip route show"? I presume you have
no specific ip rules?
Just curious.
Axy
On 10/8/23 15:08, Mario Marietto via Dng wrote:
> 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 <http://192.168.20.2/24>)
> 7. Configured IP address in the same subnet for br1 on KVM host
> (192.168.20.1/24 <http://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> <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> <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> <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> <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> <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>
> <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>
> <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>
> > > <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>
> > <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.
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] Fwd: Can't ping outside o…
