TigerVNC fails remote desktop connection with correct iptables rules

JockVSJock · 01-27-2016, 11:14 PM

Running two RHEL6 vm servers in a test environment.

I'm trying to test TigerVNC from one to another and with what I think are the correct IPTables rules, and it won't work. If I flush IPTables, it works.

Here are the rules that I've added in INPUT and OUTPUT chains

Code:

-A INPUT -p tcp -m tcp --dport 5900
-A INPUT -p tcp -m tcp --dport 5901
-A INPUT -p tcp -m tcp --dport 5902 

-A OUTPUT -p tcp -m tcp --sport 5900
-A OUTPUT -p tcp -m tcp --sport 5901
-A OUTPUT -p tcp -m tcp --sport 5902

Once I have IPtables running, here is the error message that I'm getting

Quote:

Connection Closed
Connection to host 192.168.122.50 was closed

From the source server, I'm not able to use netcat to determine if the port is open, nc -z -v 192.168.122.50:5900.

On the server itself, if I run nmap against it it comes back saying those ports are open

Code:

5900/tcp open vnc 
5902/tcp open vnc-2

If I use nmap from the source, on port 22 shows open.

Under /etc/sysconfig/vncservers I have the following two lines:

Code:

VNCSERVERS="2:JockVSJock" 
VNSERVERSARGS[2]="-geomertry 800x600"

However, again, if I drop iptables it works.

baldur_1 · 01-29-2016, 07:18 PM

this should be the code you use to open the port...

Code:

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

vincix · 01-30-2016, 08:28 AM

Quote:

Originally Posted by baldur_1

this should be the code you use to open the port...

Code:

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

What you're suggesting is simply a narrowed-down version of what the OP has written. It's as you were suggesting to turn the tap down when he doesn't have enough running water. Moreover, -m state is not recommended anymore since kernel 3.10 or so (I think). It's been superseded by -m conntrack --ctstate NEW

vincix · 01-30-2016, 08:33 AM

@OP. Perhaps there are some other rules before the rules you're showing us that are blocking your traffic? Do you normally have a stateful type of firewall? Do you have an ESTABLISHED,RELATED rule first? Maybe if you showed us more of your iptables?

You might also have something in the OUTPUT chain that could restrict your traffic...

JockVSJock · 01-30-2016, 10:42 AM

Quote:

Originally Posted by baldur_1

this should be the code you use to open the port...

Code:

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

I've tried to add this in for port 5900 and 5902 and still a no go.

Quote:

Originally Posted by baldur_1

this should be the code you use to open the port...

Code:

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

I've tried to add this in for port 5900 and 5902 and still a no go.

Code:

Now I'm getting Connection Closed 

Connection to host 192.168.122.50 was closed

This is after I've tried using 192.168.122.50:5900 and 192.168.122.50:5902.

This is what the iptables rules looks like

Code:

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5902 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5900 -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5900
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5902 
COMMIT

JockVSJock · 01-30-2016, 11:16 AM

I've just noticed this:

Code:

netstat -tulpn | grep vnc 

tcp 0 0 *:5901  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:5902  *:*  LISTEN 2315/Xvnc 
tcp 0 0 *:6001  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:6002  *:*  LISTEN 2315/Xvnc 
tcp 0 0 *:6001  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:6002  *:*  LISTEN 2315/Xvnc

I think iptables needs to accommodate this ports, however if I drop iptables on both servers it still isn't working...

vincix · 01-30-2016, 01:27 PM

Quote:

Originally Posted by JockVSJock

I've just noticed this:

Code:

netstat -tulpn | grep vnc 

tcp 0 0 *:5901  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:5902  *:*  LISTEN 2315/Xvnc 
tcp 0 0 *:6001  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:6002  *:*  LISTEN 2315/Xvnc 
tcp 0 0 *:6001  *:*  LISTEN 3357/Xvnc 
tcp 0 0 *:6002  *:*  LISTEN 2315/Xvnc

I think iptables needs to accommodate this ports, however if I drop iptables on both servers it still isn't working...

So then what did you do in the meantime that vnc isn't working anymore at all? You obviously need to get it up before you can troubleshoot your iptables rules

JockVSJock · 01-30-2016, 01:54 PM

Quote:

Originally Posted by vincix

So then what did you do in the meantime that vnc isn't working anymore at all? You obviously need to get it up before you can troubleshoot your iptables rules

The network issue is incorrect network setting in VirtualBox...now that that's fixed, I can focus on IPTables.

vincix · 01-30-2016, 02:02 PM

First of all, yes, you definitely need to allow the ports that show up in the netstat.

Secondly, your output rules don't make too much sense, unless you're (only) a client connecting to another tigervnc server. I'd suggest simply flushing the OUTPUT chain and have a simple ESTABLISHED,RELATED rule and see how that goes. Or keep them if you're also connecting from it and add the ESTABLISHED,RELATED rule at the beginning of the OUTPUT chain.

JockVSJock · 01-30-2016, 06:30 PM

First this is a test environment, not production.

Quick recap:

There are two vms, vncserver (192.168.122.50) and client (192.168.122.150). If I drop iptables, it works. Leaving iptables up, we get the following error:

Code:

Connection closed 
Connection to host 192.168.122.50:5902 was closed

Doing some quick checks, shows the following

Code:

nc -v -z 192.168.122.50 5900
nc: connect to 192.168.122.50 port 5900 (tcp) failed:  Connection refused 

server vncserver status 
Xvnc (pid 1681) is running...
chkconfig vncserver on 

nc -v -z 192.168.122.50 22 
Connection to 192.168.122.50 22 port [tcp/ssh] succeeded! 

nc -v -z 192.168.122.50 5900
Connection to 192.168.122.50 5900 port [tcp] failed:  Connection refused 

nc -v -z 192.168.122.50 5901 
Connection to 192.168.122.50 5901 port [tcp] failed:  Connection refused 

nc -v -z 192.168.122.50 5902 
Connection to 192.168.122.50 5902 port [tcp/*] succeeded!

Here is the current iptables rules on the vncserver

Code:

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT FORWARD [0:]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 21 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m state --staet NEW,ESTABLISHED -m tcp --dport 5900
-A INPUT -p tcp -m state --staet NEW,ESTABLISHED -m tcp --dport 5901
-A INPUT -p tcp -m state --staet NEW,ESTABLISHED -m tcp --dport 5902
-A INPUT -p tcp -m state --staet NEW,ESTABLISHED -m tcp --dport 6001
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5900
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5901
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5902
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 6001
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 21 -j ACCEPT
COMMIT

vincix · 02-02-2016, 01:28 PM

Code:

-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5900
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5901
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5902
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 6001
-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 21 -j ACCEPT
COMMIT

I still don't think your OUTPUT rules are correct. You only need ONE rule for related,established at the beginning of the chain:

Code:

-a output -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

Any traffic that starts from the machine will be matched against this first rule, and if it's already established, it will be accepted.
Then all you need are rules with state NEW and nothing else. If write directly "-A OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 5902", then this rule won't be taken into consideration, because it can never begin, there's no "NEW" state, if you understand what I mean.

Of course, I'm talking more about iptables principles rather than your current problem. Anyway, do allow port 6002 also. I see that you've forgotten about it, but it does show in your netstat.

Another thing about your INPUT chain: it's slightly redundant. Again, if you have a related,estalished rule at the beginning of the chain, you don't need to repeat either the related or the estalished state in any rules afterwards. "NEW" is enough. Then, when the traffic is checked, again, it starts with the first rule and it's accepted, because it's established. I hope I'm clear enough and haven't overexplained things.

So for your INPUT chain you can have the following:

Code:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5900
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5901
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5902
-A INPUT -p tcp -m state --state NEW -m tcp --dport 6001
-A INPUT -p tcp -m state --state NEW -m tcp --dport 6002

By the way, what kernel are you using? I'm not sure, but it might not react well starting from a certain kernel version (3.10 I think). Although some say that -m state is simply an alias to conntrack --ctstate.
For instance:

Code:

-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 6002

It might make no difference, of course.