I have a local network connected through a router with 2 computers:
an http server S outside the router firewall (DMZ)
a computer C inside the router firewall
Both use the most recent Comodo FW 3.x. Both are set to Custom Policy Mode, Defense+ disabled.
The router DHCP server is set to always assign the same IPs to these 2.
I use Remote Desktop (RD) to control S from C.
On S Comodo FW I added a rule to allow several addresses from the local pool, including the one from C.
Initially, I can’t connect with RD from C to S. If I disable the FW on S, I can then connect from C to S with RD. Then, If I close RD, enable the FW on S, I can’t connect any more.
If on the other hand I disable the FW on S, connect with RD from C to S, and re-enable the FW while connected with RD (from RD itself), then I remain connected, and from that point on, I can close RD and open it repeatedly and it will work.
But if I restart S, again, I won’t be able to connect, and I have to repeat the process to gain access to S using RD.
Anybody knows how I can set things to make sure I am always allowed to connect from C to S using RD.
First question, which may lead to other questions, is what the server ( S) CFP logs are showing. From your description, it sounds like something is being blocked during the remote desktop initialization. That initialization may be using some unexpected protocol (either by port, IP protocol itself, or LAN broadcast address) that the server CFP rules are blocking.
The next step, would be to drop in a network monitor like Wireshark onto your client (C) machine, and see what’s going on during a connection process, both when it works and when it doesn’t.
Here is a portion of the server CFP log relevant to this issue (server …0.7, client …0.10)
Date/Time Application Action Source IP Source Port Destination IP Destination Port
6/1/2008 5:46:47 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 2041 192.168.0.7 3389
6/1/2008 5:46:50 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 2041 192.168.0.7 3389
6/1/2008 5:46:56 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 2041 192.168.0.7 3389
6/1/2008 9:11:21 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1040 192.168.0.7 3389
6/1/2008 9:11:24 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1040 192.168.0.7 3389
6/1/2008 9:11:30 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1040 192.168.0.7 3389
6/1/2008 9:11:43 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1041 192.168.0.7 3389
6/1/2008 9:11:46 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1041 192.168.0.7 3389
6/1/2008 9:11:52 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1041 192.168.0.7 3389
6/1/2008 9:26:46 PM C:\WINDOWS\system32\svchost.exe Blocked 192.168.0.10 1120 192.168.0.7 3389
etc…
If I am not mistaken, the first time a connection is accepted by the user, CFP automatically creates a rule for that, but somehow none was present for the Remote Desktop service. So I just created that rule (allow inbound connections from 192.168.0.10 on port 3389 to svchost.exe). It’s working now, but I haven’t restarted the server yet, so I’ll see if it still works when I restart it.
You are right that CFP will create a rule, but that is for outbound traffic so as to allow a reply to come back to that originating port. If you’re getting an inbound packet by itself, then CFP will block as there is no matching listener.
I don’t know the protocol sequence that remote desktop uses, but it sounds like the client machine contacts the server, then the server sends back to the client port 3389 expecting the client to be listening. CFP doesn’t recognize remote desktop as a protocol sequence, so the inbound 3389 was getting blocked. A wireshark trace would confirm that, but setting CFP rules as you’ve done seem to be working.
Just for reference, to make it work right, I had to move up the new Remote Desktop rule above the rule that denies all inbound connections to this module. The order is relevant, as packets are checked against rules in the order these are presented in the Network Security Policy dialog.
