Disclaimer: I know this is a bad idea. I’m doing it anyway.
I’m trying to get Synergy 3 working in Qubes. I have it installed in dom0. I managed to port forward my way to a configuration where I can connect to it from an external Windows box, and Qubes can control the Windows system. However, if I want the Windows system to control Qubes I need Synergy, in dom0, to be allowed an outbound connection from a random port to the Windows box.
Inbound was fairly easy, but this outbound eludes me.
I see this thread, and I think I see using socat to pass a connection request from Synergy on dom0 to another Qube, but I’m not sure how to then pass it along to the Windows system, or if there’s an easier way. I’m looking for thoughts. I feel like I’m 90% there, but the actual chain outbound escapes me.
I’m assuming I need Synergy in dom0 to open a connection to socat localhost:someport > pass that over to some synergy Qube > pass that out to the Windows Synergy server? I think I can do the first bit, but I’m unsure what the best way to pass that last bit is. Just another socat/netcat? Something else?
Let me know what you think.
So I was also wrong about getting the first step to work. The problem is Synergy, as a client on Linux in dom0 wants to connect to port 24800, and as a server it runs on 24800. So I can’t even say ‘connect to localhost:24800’ and use socat to redirect that.
I either need a way to just allow outbound connections from dom0 directly to sys-firewall, or I need Synergy to redesign their networking stack.
Unfortunately Synergy is already running on 24800 on dom0. It also wants to connect to the other system on 24800. It appears I may be able to change the port number, but the documentation is unclear how that is actually done (Synergy - What ports does Synergy use?). Currently have a ticket open to the dev. If they provide me with the steps for telling a client to use a different port I think I’ll have this solved. Your method looks very similar to the one I was trying when I realized there would be a port overlap, so I’m glad I was on the right track.
My only other concern is the client refusing to properly connect to 127.0.0.1. I think it’s going to auto-detect itself and say “You’re already connected.”
One thing at a time, though.