On Monday, 27 September 2021 at 13:58:47 UTC+1 unman wrote:
> On Mon, Sep 27, 2021 at 02:35:34AM -0700, mgla...@gmail.com wrote:
> >
> > Hi everyone,
> >
> > I'm looking for some help as to how to diagnose some app-VM networking
> > issues. I have 2 vms, both based on the same template with identical
> > config, but one can reach the internet and the other cannot.
> >
> > Before upgrading:
> > 2 standalone VMs based on Fedora-30. One with a bunch of dev tools
> > installed, one relatively untouched. I had multiple VMs based on these
> two
> > templates. I also updated my sys-net and sys-firewall to Fedora-33 at
> the
> > same time.
> >
> > Upgrade:
> > I upgraded to Fedora-33, and realised I could rationalise my VMs, so now
> > every appVM is based off the same Fedora-33 template.
> >
> > The issue:
> > Some of my migrated VMs are completely fine, others have no network.
> > I _think_ it is the VMs that used to be based on my old "untouched" vm
> that
> > have the issue.
> >
> > VM1:
> > No networking at all.
> >
> > VM2:
> > Networking is completely fine, everything works as expected.
> >
> > Both VMs are based on the same Fedora-33 template, with the same
> (default)
> > sys-firewall Networking, both with the firewall configured to allow all
> > outgoing internet connections
> >
> > *vm1$ ping google.com*
> > ping: google.com: Name or service not known
> >
> > *vm1$ dig google.com*
> > ; <<>> DiG 9.11.35-RedHat-9.11.35-1.fc33 <<>> google.com
> > ;; global options: +cmd
> > ;; connection timed out; no servers could be reached
> >
> > *vm1$ resolvectl dns*
> > Global: 10.139.1.1 10.139.1.2
> > Link 2 (eth0):
> >
> >
> > *vm2$ resolvectl dns*
> > Global: 10.139.1.1 10.139.1.2
> > Link 2 (eth0):
> > Link 3 (br-11bfb2cd10e9):
> > Link 4 (docker0):
> > Link 5 (br-cf58034d074b):
> > Link 6 (br-f9686c41a7f5):
> >
> > So there's definitely something wrong, but I don't know enough about
> > Linux/Qubes networking to work out what.
> >
> > Any pointers gratefully received.
> >
>
> There is something wrong, but there is nothing in the detail you have
> provided that might explain it.
> So:
> Do you have any custom firewall rules set on vm1? (qvm-firewall vm1)
> Can you ping the firewall from vm1, by IP address?
> Can you access a host on the internet by IP address?(e.g https://9.9.9.9)
> If you create a new qube from the template, does networking work as
> expected?
> If you change templates on vm1, does networking work?
>
Yes, there are custom firewall rules, but the firewall is set to "Allow
all outgoing internet connections". Which should ignore all the rules?
Yes, I can happily ping sys-firewall's IP from both vm1 and vm2.
No, I can't access a host on the internet by IP
vm1$ curl https://9.9.9.9
curl: (7) Failed to connect to 9.9.9.9 port 443: No route to host
Yes, creating a new qube from the same template works fine - networking is
exactly as expected.
No, changing templates on vm1 doesn't fix it (I thought it did when I tried
a month or so ago, but I just gave up without really trying to get to the
bottom of what's wrong. Either way, it doesn't work now)
Changing vm1's network from sys-firewall to sys-net doesn't fix it, either.
But this is interesting though. This is what I get when pinging the IP of
sys-net (whilst networking is set to sys-firewall):
vm1$ ping 10.137.0.5
PING 10.137.0.5 (10.137.0.5) 56(84) bytes of data.
>From 10.137.0.6 icmp_seq=1 Packet filtered
>From 10.137.0.6 icmp_seq=2 Packet filtered
>From 10.137.0.6 icmp_seq=3 Packet filtered
[...]
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2077ms
(0.5 is the IP of sys-net and 0.6 is sys-firewall)
So somehow when I ping sys-net I get a response from sys-firewall. Huh!?
This is what happens on my working VM:
vm2$ ping 10.137.0.5
PING 10.137.0.5 (10.137.0.5) 56(84) bytes of data.
64 bytes from 10.137.0.5: icmp_seq=1 ttl=63 time=0.286 ms
64 bytes from 10.137.0.5: icmp_seq=2 ttl=63 time=0.529 ms
64 bytes from 10.137.0.5: icmp_seq=3 ttl=63 time=0.551 ms
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/bdd741ec-f8c0-4747-b531-5f7a79a923abn%40googlegroups.com.
