Unreliable under Fedora 35? Under some circumstances, gnome-remote-desktop remains unreachable for VNC even on a LAN
Hi!
A family computer I maintain has the latest GNOME on Fedora 35 configured to allow remote desktop (VNC) connections with simply a password, and I turned it on for the wifi interface the computer connects through.
I'm trying to access it via Remmina, and no matter what I do (even through an SSH tunnel, yet SSH works) it doesn't connect.
This may or may not be a bug (I don't know) but I don't know where else to turn to. I've tried asking the Twitter hivemind here and ran out of ideas. The weirdest part is that for some other Fedora 35 machine, it works, and I can't tell what the difference is.
Anything other than local loopback VNC fails. I think I tried every possible client software and network configuration. Remmina, "GNOME Connections", etc; tried under GNOME's Wayland session, Xorg session, with password auth vs click-to-authorize; tried LAN-only (direct VNC or RDP connection attempt to the local/LAN IP), disabled SELinux; poked runtime & perm holes for every service (vnc-server, RDP, cockpit, SSH) in firewall-config (or even uninstaling firewalld); tried with & without a SSH tunnel in Remmina. I was not ever able to connect to that GNOME 41 / F35 desktop remotely even in the same LAN.
The only thing that sort-of worked was testing VNC to 127.0.0.1 with GNOME "Connections", and seeing that it seems to kinda work under the Xorg session (and unreliably under the Wayland session).
On the affected machine:
journalctl -f -b /usr/libexec/gnome-remote-desktop-daemon
only gives me: jan 11 12:59:05 computer gnome-remote-de[40300]: Initialized VNC server
The firewall is wide open and includes the "vnc-server" service allowed (and the 5900 port is correctly forwarded on the router/NAT):
# firewall-cmd --list-all
FedoraWorkstation (active)
target: default
icmp-block-inversion: no
interfaces: wlp2s0
sources:
services: cockpit dhcpv6-client mdns rdp samba-client ssh vnc-server
ports: 1025-65535/udp 1025-65535/tcp
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
# tcpdump -i wlp2s0 -nn tcp port 5900
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:45:21.724585 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638937113 ecr 0,nop,wscale 7], length 0
12:45:22.726432 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638938115 ecr 0,nop,wscale 7], length 0
12:45:24.774442 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638940163 ecr 0,nop,wscale 7], length 0
12:45:28.806449 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638944195 ecr 0,nop,wscale 7], length 0
12:45:36.998449 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638952387 ecr 0,nop,wscale 7], length 0
12:45:53.382432 IP 192.168.0.101.60580 > [the_server_IP_on_the_internet].5900: Flags [S], seq 3089894624, win 65392, options [mss 536,sackOK,TS val 2638968771 ecr 0,nop,wscale 7], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
I configured the firewall through cockpit and/or the firewall-config GUI. As far as I can tell it's opened properly. Remmina's debug output gives me no clue about the cause of the problem. I even disabled IPv6 just to be sure.
What else do I need to be checking/troubleshooting to make this work? The GUI in gnome-control-center makes it look like everything is good but doesn't help in determining what the issue might be, or if the server is reachable at all from the outside; but in this case, I was not even able to reach it from a computer within the same LAN, so at this point I'm thinking I might be hitting a g-r-d bug of some kind rather than a network problem.