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!!