SPICE - listening ports
Responses
Hej Pär,
Unfortunately using the interface can be a bit challenging. You may be able to still edit your first post. If so, try clicking on "Source" and inserting your update there and then click save. I think all of us have been through the process of discovering how the tool messes up our posts sometimes.
Like this?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hi, # virsh -r list --all Id Name State ---------------------------------------------------- 1 se06inpidaydb1 running 2 se06inpinfapp1 running # netstat -tulpn |grep :59 tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 11566/qemu-kvm tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 11566/qemu-kvm tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN 11638/qemu-kvm tcp 0 0 0.0.0.0:5903 0.0.0.0:* LISTEN 11638/qemu-kvm Every VM seem to spawn two ports for spice connections.I guess my source adress must be able to communicate with both ports for the VM console to work? Will it always be 2 spice ports per VM? Would be good to know since then I know the port range that needs to be opened. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Spice requires two ports, one for the encrypted channels and one for the unencrypted traffic. The range is predefined for you in the host iptables and is mentioned in the RHEV guides as well.
Back to the question:
Info about port ranges can be found here:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html/Administration_Guide/Virtualization_Host_Firewall_Requirements1.html
IIRC, for each process an unsecure and a secure port is opened.
"5634 - 6166 is a lot of ports. And when is ports below 5900 used?"
I'm not sure how the mechanism of selecting ports works and I can't find any documentation at RHN that explains this, but I have some virtual machines running at ports lower than 5900. So somehow ports below 5900 do get assigned.
How the ports are selected doesn't really matter here. The spice port range is 5634-6166, that's 532 ports, which means you can have 266 VMs there without changing the port range. If you use VNC, you can have double, because VNC only uses a single port.
I suppose you are looking into a NAT solution for spice in your environment, if you are asking about ports, and generally speaking, port forwarding will not work here- the range is wide and dynamic, and there are better, more secure solutions.
I would set up a separate display network and open only the spice ports on that, and then put the interface in the user network VLAN. This way, firewall or not, there will be nothing listening unless a VM is started, and when a VM is started, you want those ports open after all
Instead of opening ports, why not have remote SPICE clients VPN into the RHEV network? Or another idea - I wonder if anyone from the Netfilter team is following this discussion and would be willing to put together a SPICE conntrack module?
for additional security, VPN them into the display network, leaving rhevm out
as for conntrack, that's an interesting idea, but it has to make it upstream first
SPICE works via iptables NAT. I had a partial solution in place where split-brain DNS would point all hostnames of Hypervisors to a singular IP (Linux router) which would then forward on the ports. This doesn't work with more than one Hypervisor though since the port ranges clash. If the Hypervisors had exclusive port ranges, this could become a viable solution for users connecting from over the WAN - and would cut down on the latency added by any VPNs. Only other ways I can think of are Public IPs for each Hypervisor, or VPN into the Display subnet.
Talking of opening a very wide range of ports unnecessarily. How does it matter if the ports are not open on the Host anyway? The purpose of a firewall is to have separate policies (based on a variety of parameters) for ports that may be open, or could be open in the future. Yes, there are frivolities like altering the response type of denied connection.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
