Can't connect to VNC server

Hoping your collective brain power can assist me...

tl;dr - Ubuntu server seems to have several ports open none can be seen by the outside (LAN) world - WTF is going on?

Longer:

I have a headless 17.04 server to which I'd like to connect using VNC, but I'm struggling at the moment. I'm using two clients - both Windows 10, one using RealVNC, one using TightVNC.

I've set up TightVNC server on my Ubuntu machine, mostly following the instructions at , intending to run Xfce as a desktop:

$ sudo apt install xfce4 xfce4-goodies tightvncserver

I've changed the xstartup file to:

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &

And granted executable privilege.

If I start the server using tightvncserver I get:

New 'X' desktop is numbersix:1
Starting applications specified in /home/adam/.vnc/xstartup
Log file is /home/adam/.vnc/numbersix:1.log

nmap localhost gives:

Starting Nmap 7.40 ( ) at 2017-11-09 21:05 GMT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000076s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 986 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
5901/tcp open vnc-1
6001/tcp open X11:1
8000/tcp open http-alt
8001/tcp open vcom-tunnel
8010/tcp open xmpp
8080/tcp open http-proxy
9091/tcp open xmltec-xmlmail

nmap 192.168.1.6 gives the same result.

I set the server as a systemd service - created /etc/systemd/system/vncserver@.service with this content:

[Unit]
Description=Start TightVNC server at startup
After=syslog.target network.target
[Service]
Type=forking
User=adam
PAMName=login
PIDFile=/home/adam/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i
[Install]
WantedBy=multi-user.target

Then started the service with

$ sudo systemctl daemon-reload
$ sudo systemctl enable
$ sudo systemctl start vncserver@1

All seems to work. sudo systemctl status vncserver@1 gives:

● - Start TightVNC server at startup Loaded: loaded (/etc/systemd/system/vncserver@.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2017-11-09 21:38:13 GMT; 6s ago Process: 3924 ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :1 (code=exited, status=0/SUCCESS) Process: 3916 ExecStartPre=/usr/bin/vncserver -kill :1 > /dev/null 2>&1 (code=exited, status=2) Main PID: 3937 (Xtightvnc) Tasks: 0 (limit: 4915) CGroup: / ‣ 3937 Xtightvnc :1 -desktop X -auth /home/adam/.Xauthority -geometry
1280x800 -depth 24 -rfbwait 120000 -rfbauth /h
Nov 09 21:38:12 numbersix systemd[1]: Starting Start TightVNC server at startup...
Nov 09 21:38:12 numbersix systemd[3916]: pam_unix(login:session): session opened for user adam by (uid=0)
Nov 09 21:38:12 numbersix systemd[3924]: pam_unix(login:session): session opened for user adam by (uid=0)
Nov 09 21:38:13 numbersix systemd[1]: Started Start TightVNC server at startup.

telnet localhost 5901 seems to connect OK:

Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
RFB 003.008

And sudo netstat -nlpt | grep :59 gives:

tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 3937/Xtightvnc

But, telnet numbersix 5901 and telnet 192.168.1.6 (from Windows) fail with:

Could not open connection to the host, on port 5901: Connect failed

And neither RealVNC nor TightVNC will connect (using hostname or IP). Ping works on both Windows hosts with IP or hostname. Also couldn't connect from Ubuntu laptop. Again, can ping. I can ssh without issues. sudo nmap numbersix from the Ubuntu laptop gives:

Starting Nmap 7.01 ( ) at 2017-11-10 12:50 GMT
Nmap scan report for numbersix (192.168.1.6)
Host is up (0.0032s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
8000/tcp open http-alt
8001/tcp open vcom-tunnel
MAC Address: 60:45:CB:64:2B:C8 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 12.85 seconds

The INPUT, FORWARD and OUTPUT chains from sudo iptables -L on the server are:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
INPUT_direct all -- anywhere anywhere
INPUT_ZONES_SOURCE all -- anywhere anywhere
INPUT_ZONES all -- anywhere anywhere
DROP all -- anywhere anywhere ctstate INVALID
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
FORWARD_direct all -- anywhere anywhere
FORWARD_IN_ZONES_SOURCE all -- anywhere anywhere
FORWARD_IN_ZONES all -- anywhere anywhere
FORWARD_OUT_ZONES_SOURCE all -- anywhere anywhere
FORWARD_OUT_ZONES all -- anywhere anywhere
DROP all -- anywhere anywhere ctstate INVALID
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
OUTPUT_direct all -- anywhere anywhere

So I think that suggests that iptables is blocking nothing...

Can anyone help me diagnose the problem, please?

1 Answer

The answer lay in my failure to understand iptables - and particularly what the output from sudo iptables -L meant...

When I instead ran sudo iptables -S, I was presented with a much fuller description of each rule, and it was obvious then that there wasn't a suitable INPUT rule that was allowing tcp traffic on 5901 (or any of the other ports I was looking at) through. Then the final INPUT rule, which was essentially rejecting everything that didn't match a rule, was collecting this traffic and rejecting it. The rule that I thought should have been ACCEPTing the traffic applied only to the lo interface (loopback).

I ran this:sudo iptables -I INPUT 7 -s 192.168.1.0/24 -i enp37s0 -j ACCEPT

That's basically inserting a rule at line 7 of the INPUT chain, and telling it to ACCEPT any traffic from the 192.168.1.0/24 subnet arriving on the ethernet port.

The next challenge is getting iptables-persistent to actually work on reboot!!