TeamViewer - asks for connection despite the rule

I have TeamViewer configured for LAN only. In addition to that, I have application rule for teamviewer.exe as follows:

Allow & Log IP In/Out
Source & Destination Address: both set to Network Zone - Trusted Hosts
IP protocol - any

Under trusted hosts zone, I have local IPs listed. Despite that, when I run teamviewer.exe on the client computer, I get a prompt (on the client computer) to allow internet connection for teamviewer.exe (the prompt includes the IP of the target, which is in Trusted Hosts already).

Is this a bug or some misconfiguration? It doesn’t make sense.

What kind of network zone are you using? (IP-Range, Subnet etc) Personally I’ve had issues when using subnets (for example 192.168.1.0 and 255.255.255.0 didn’t give me 192.168.1.0 to 192.168.1.255 so I don’t know how Comodo processes subnets)

Edit: The issue I mentioned above was many many releases ago though, so probably fixed by now, I can’t replicate the issue anymore.

Comodo Firewall Subnet Masking working perfectly fine. I couldn’t imagine something as basic as that to have an issue with.

When you testing, keep in mind private IP addresses are tested for devices behind it first. If there is no response, your TCP, UDP, and ICMP rules won’t get triggered when doing the tests.

@Max2015: Create another application rule for TeamViewer, have it block all & log. Relocate this rule to the very bottom and save changes and run your TeamViewer and test again. Keep an eye on the logging.

The rule you already created either is misconfigured or there is something else you didn’t consider that TeamViewer does for connections. Like phoning home to check for software updates. :wink:

@ Sanya: No subnets, just “IPv4 Single Address” for those few.

@ Phant0m: Wouldn’t that rule be the same as my answering Block to that question (which I did, and the client could not connect then; there was nothing special in those log entries, other than me on local_ip_1 blocked from connecting to local_ip_2, both listed in Trusted Hosts)?

Yes, phoning home was there until I figured out all the settings. Now it’s all local, but still…

Go through TeamViewer application rules again, and over the Network Zone one. Ensure you didn’t by mistake choose ‘Exclude’.

The problem is you should never create an in/out rule with source and destination addresses set. You should create a specific outgoing rule with destination address being the trusted hosts network zone, and an allow incoming rule with the source address set to the trusted hosts network zone then below those rules create a block in/out rule with source and destination address set to any. The following list is what the rules should be set as for only allowing LAN access for the application:

  1. Action:Allow, Protocol:IP, Direction:Out, Source address:any, Destination address:Network Zone:Trusted Hosts, IP details:Any
  2. Action:Allow, Protocol:IP, Direction:In, Source address:Network Zone:Trusted Hosts, Destination address:any, IP details:Any
  3. Action:Block, Protocol:IP, Direction:In/Out, Source address:any, Destination address:any, IP details:any

If both parties are always supposed to be in the same network zone then it shouldn’t matter. (I have several such rules and haven’t had any issues with them)

Your forgetting that Teamviewer uses Port Punching to get around standard firewalls by using an intermediary server to handle the socket exchange, as the port will be randomized for every session and there’s no way to override. I believe they also removed the advanced option to only do local traffic for LANs on the free version.

Since there’s no way to override the port randomization, they only way to avoid alerts is to set the rule to ‘Allow Application’.

There’s nothing wrong with including source and destination IP addresses provided in a single rule.

If you creating a bi-directional rule in Comodo Firewall, simply to allow locally initiated client communications. Bi-directional rule would be unnecessary. Stateful Packet Inspection mechanism in Comodo will automatically handle the typical reversed associated traffic.

Bi-directional rules required to permit also remotely initiated access to locally running services on your computer.

Yes if the IP address that get assigned to your computer is in the network zone it will work, but I’m betting the OP created a network zone that contained only IP address of other devices on the LAN but not the IP address of the client computer on which comodo is installed. e.g. client computer has an address of 192.168.1.3 and computer A address 192.168.1.4 and computer B 192.168.1.5, the network zone then contains only computer A and B address so the allow in/out rule won’t work.

Most people who create a trusted network zone add individual IP address of the other devices they trust but don’t include the address of their computer, instead of using the subnet mask address type.

And that’s exactly the case. :slight_smile: I thought localhost IP/subnet suffices there. I’ll give it a shot. So this applies only in case there is one in/out rule? (Meaning if I split the rule in two, I can leave the own IP out of that zone?)

Correct, you need to create two separate In and Out rule when the network zone does NOT contain the LAN IP address of the computer you are setting the rules on. Localhost and the LAN IP address are two different addresses and so if you wanted to use a subnet mask for the network zone, you would have to fill in the LAN IP address as the IP in the subnet mask window. e.g. 192.168.1.4 255.255.255.0 and not the localhost IP of 127.0.0.1