Unable to connect to CentOS 7/8 Screen Sharing (VNC) over work VPN

Question

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.

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?

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 01 '20 at 22:24
@DarkVex I've tried both to no avail. When I use the current settings, I can connect to localhost, which prompts me with "Allow 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 02 '20 at 01:11
@Argyle the VPN Concentrator/Server that your company use it's a dedicated system or it's an UTM Firewall like Sophos, PFSense? If it's an UTM it might be possible that there is a policy that allows you to connect through SSH to the system but not to VNC — DarkVex, Aug 04 '20 at 16:39
@DarkVex I checked with the person who manages the routers/VPNs. We're using a combo of Cisco ASA 5512X and Cisco ASA 5516X. According to them, there's no policy specifically set or enabled that would block VNC. If there's something specific they should check, do let me know and I'll ask them to check. — Argyle, Aug 04 '20 at 17:16
`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 05 '20 at 16:31
@mforsetti This was it! I opened tcp/udp 5900 and it works. Can you please resubmit your response as as answer so I can award you the bounty? If you can add the iptables commands to allow 5900 on tcp/udp, I'm sure it would be greatly helpful to the SF community. If not, I can do it in a reply. Thanks so much! — Argyle, Aug 05 '20 at 20:14

score 1 · Accepted Answer · answered Aug 06 '20 at 02:55

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

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

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.

Unable to connect to CentOS 7/8 Screen Sharing (VNC) over work VPN

1 Answers1