I have a laptop from work and need to do a remote connection through terminal services in WinXP SP2. But Comodo is blocking this connection. I know it is Comodo’s fault because when I allow all traffic through Comodo, the remote connection works fine.
Watching the activity logs as I try to connect, I see 3 entries for:
Inbound Policy Violation (Access denied, IP=my IP, port=4449)
When I terminate the attempt, I see one more entry for:
Inbound Policy Violation (Access denied, IP=my IP, port=nbdgram(137)
The only network blocking rule is the standard:
Block and Log IP In or Out from IP [Any] to IP [Any] where IPPROTO is ANY
What is an IPPROTO? What does this rule do???
Why don’t I see some sort of popup asking for my permission to allow this connection? I tried cranking the security up to VERY HIGH and still did not see any popups. ???
I have a laptop from work and need to do a remote connection through terminal services in WinXP SP2. But Comodo is blocking this connection. I know it is Comodo's fault because when I allow all traffic through Comodo, the remote connection works fine.
Do you know what kind of Terminal Server you are connecting to, is it for example Citrix Presentation server, Microsoft Terminal Server or perhaps a UNIX box?
Watching the activity logs as I try to connect, I see 3 entries for:
Inbound Policy Violation (Access denied, IP=my IP, port=4449)
When I terminate the attempt, I see one more entry for:
Inbound Policy Violation (Access denied, IP=my IP, port=nbdgram(137)
Do you have any other alerts in the log files, perhape for ‘outbound’ connections?
The only network blocking rule is the standard:
Block and Log IP In or Out from IP [Any] to IP [Any] where IPPROTO is ANY
What is an IPPROTO? What does this rule do?Huh
IPPROTO Stands for IP Protocol, i.e. TCP and UDP amongst others.
Why don't I see some sort of popup asking for my permission to allow this connection? I tried cranking the security up to VERY HIGH and still did not see any popups. Huh
Do you have any rules defined for RDP in Application Monitor, if so delete them and try the connection again. make sure you have the Alert Frequency set to Very High.
For your interest, if your using a standard Microsoft Terminal Server and Client, it uses the Remote Desktop Protocol (RDP) which uses port 3389 for all communication.
Another question to ask is, do you need to establish a secure connection between your client and the server i.e. a VPN connection?
The first this to check is that you are able to successfully make a VPN connection to the host computer. I assume you already have a VPN connection configured in Network Connections.
If you find you cannot establish a connection, you will need to ensure you have allowed TCP In/Out for port 1723. This being the common port for VPN connections using PPTP. You will also need to make sure GRE is enabled in Network Monitor.
Assuming you can establish a VPN connection, you will now have to allow the Remote Desktop Service (Mstsc.exe - Windows\System32\Mstsc.exe) through the firewall. To do this create an application rule in Application Monitor for Mstsc.exe TCP Out on port 3389.
Hopefully that should work. Let me know if you have any problems.
Hmm, just a thought, if your VPN is using L2TP and IPSec its slightly different. If this is the situation you will need to allow UDP port 1701 for L2TP, UDP port 500 for IPSec and you will need rules in Network Monitor for Protocol 50 (ESP - Encapsulated Security Payload) and 51 (AH - Authentication Header)
This is pretty complicated. I think part of the issue may be the VPN connection. But I have not seen any Comodo prompts related to the VPN. If Comodo isn’t presenting me with all the information I need, then how can I address issues like this?
I’ve looked at the Windows firewall settings and frankly, there isn’t much there in the exception tab. Supposedly, WF is blocking everything except what is in the exceptions tab. Here is what is listed in this tab:
C:\Windows\System32\dpmw32.exe
C:\Arcip\host32.exe
4 HP files (this is a Compaq laptop)
C:\Windows\Network Diagnostic\xpnetdiag.exe
C:\Windows\system32\sessmgr.exe
TCP 3389 ANY (Remote desktop)
On the WF Advanced tab, there is:
adsl
hutz
Local Area Connection
Wireless Network Connection
Neither of these entries have any settings enabled under Settings button.
As an aside, it would be VERY helpful if Comodo could compare the settings in WF during initial install, list them out and then allow for their import into Comodo format before turning off the WF.
I don’t know because I don’t get any messages related to the VPN from Comodo.
The company system guy added some rules to Comodo to allow the VPN to work. He put these rules in the NM:
Allow “some IP range” 0-254
Allow Zone [NAME] “some IP range” 0-255
Allow TCP/UDP on one particular IP
Unfortunately, he tried to use logic. However, Comodo isn’t logical and AFAIK, there is no purpose or value to putting anything in Comodo’s NM expect block statements. If you DON’T block something in the NM, then it allows anything else through, where the AM is supposed to pick up. If you delete (or turn off) all the ALLOW rules out of the NM, then I don’t believe it will make any difference whatsoever.
So I believe the rules he tried to enable in the NM have to go in the AM instead. I’ll experiment with trying to figure out how to do this and report back.
First, I was wrong above at how the NM works. With the standard block rule (at the bottom) in NM:
“Block and Log IP IN or OUT from IP [Any] to IP [Any] where IPPRPTP is ANY”
everything will be blocked by default EXCEPT for whatever you pass through via “Allow” rules above this block rule.
So, I had to add an ALLOW rule allowing traffic for port 4449 through. That didn’t solve the problem though.
So I next added an AM rule allowing the main VPN file through the IP range it needed.
After doing this, I then got 3 other Comodo prompts for the main VPN file on 3 IP addr’s. Allowing these prompts fixed the problem.
I think much of the problem in figuring out what was going on here was due to the rather poor Comodo messages that appear in the log file. I mean, what is one to make of:
Inbound Policy Violation (Access denied, IP=my IP, port=4449)?
It would have been a lot more helpful IF CPF would have included the file/module that was creating this request, instead of being only able to provide my IP addr and a port reference. This is because in Comodo, in order to creat an AM rule, you have to know the application name to put in during rule creation. You can’t just create a rule for any particular port that applies to all applications.