0

As with most people, we're WFH. It's getting difficult to troubleshoot issues via chat/phone, so we'd like to use the CentOS "Screen Sharing" feature, which comes bundled with the OS, to allow support personnel to connect to user machine's to assist with their issues. The support personnel will also used to built in client vinagre with VNC selected as the connection type.

All users are connected to a VPN that is configured to allow internal hosts to communicate with one another. We can ping other hosts, view services they're running, etc. Here is my machine's Screen Share settings.

Screen Sharing settings window

When I look at netstat, I see port 5900 is listening on tcp6. I considered the issue was the underlying VNC server was listening on IPv6 when every hosts IPv4 interface is set as the default connection, but I recall reading somewhere that tcp6 connections map to tcp4 connections, so it's supposedly a non-issue. Here's my netstat output:

$ sudo netstat -nlt 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:10391         0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN     
tcp6       0      0 :::5355                 :::*                    LISTEN     
tcp6       0      0 :::5900                 :::*                    LISTEN     
tcp6       0      0 :::111                  :::*                    LISTEN     
tcp6       0      0 ::1:631                 :::*                    LISTEN     
tcp6       0      0 :::9090                 :::*                    LISTEN    

I considered it was the firewall, but both my machine and the client machine have firewalld disabled.

Here is the output of nmcli to show the settings of Wired Connection 1

enp57s0u1: connected to Wired connection 1
    "Realtek RTL8153"
    ethernet (r8152), 8C:04:BA:67:52:16, hw, mtu 1500
    ip4 default
    inet4 192.168.1.123/24
    route4 0.0.0.0/0
    route4 192.168.1.0/24
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64
    route6 fe80::/64
    route6 ff00::/8

Finally, I tested enabling SSH and it worked. Users were able to connect and were prompted to authenticate (we didn't have them actually log-in). This leads me to believe it's an issue with the underlying VNC server itself, something maybe related to it listening on tcp6 above?

Any idea what the issue may be?

9
  • 1
    Check your firewall. – Michael Hampton Aug 1 '20 at 22:09
  • Did you tried to change the Access option by setting up a password instead of use "New connections must ask for access"? The current setting if I recall properly will shown a pop-up on the server side for allow the connection and until someone doesn't click on it the connection will hangs – DarkVex Aug 1 '20 at 22:24
  • @MichaelHampton The firewalld is disabled. – Argyle Aug 2 '20 at 1:10
  • @DarkVex I've tried both to no avail. When I use the current settings, I can connect to localhost, which prompts me with "Allow <ipv6 IP> to connect" but the connection is closed when I accept the connection. When others attempt to connect, they get some variation of "Connection Refused" and I never receive a prompt to allow them to connect. – Argyle Aug 2 '20 at 1:11
  • 1
    firewalld disabled doesn't mean there's no firewall. Run iptables -nL and nft list tables, and check if you had any rules there, including chain rule (e.g. Chain INPUT (policy ACCEPT) means your ingress is open). Also, please run netstat -pnlt and show the result. – mforsetti Aug 5 '20 at 16:31
1
+50

Checking netstat and firewalld is correct, but a few tips:

  1. Disabled firewalld doesn't mean you don't have any firewall set, i.e. netfilter can be controlled by iptables and nftables, so you may need to check that too.
    $ iptables -nL
    $ nft list tables
  1. Always check for PID/Process name when you're doing network service diagnostic, i.e. netstat -nltp or ss -nltp. When something goes wrong, you can always check said service's logs and configurations.

If you can add the iptables commands to allow 5900

Should be something like

$ iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT
$ iptables -A INPUT -p udp -m state --state NEW -m udp --dport 5900 -j ACCEPT

if you're using nftables, you can do something like

$ nft add table inet t_gnome_vnc
$ nft add chain inet t_gnome_vnc c_input
$ nft add rule inet t_gnome_vnc c_input tcp dport 5900 accept
$ nft add rule inet t_gnome_vnc c_input udp dport 5900 accept

PS:

I recall reading somewhere that tcp6 connections map to tcp4 connections, so it's supposedly a non-issue.

It is called dual-stack mode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.