First a short introduction of WiDi for those who are not familiar with it: Intel® Wireless Display (WiDi) is an Intel proprietary system for wireless connection of a laptop to a TV. It requires a laptop with a 3rd generation Intel® Core™ Processor and a TV with HDMI and an external wireless adapter (there are also now a few TVs with integrated adapters). WiDi uses the normal WiFi card to connect to the WiDi adapter simultaneously with performing its normal task of connecting to a WiFi router for Internet. The WiDi software creates a Microsoft Virtual Miniport that connects to the TV adapter and provides it with an IP-address.
So far, so good. In my case, unfortunately, my firewall blocks the TV adapter from receiving its IP address. This seems to be a common problem and is mentioned in the WiDi Help section. And sure enough, if I first disable my Comodo firewall, then set up the WiDi link and finally set the firewall back to Safe Mode again, then everything works fine, but only then. To escape that situation, I have spent a lot of time trying to identify all program files and processes that I believe are associated with WiDi and then define them as trusted applications. I have even identified (I think) the program that does the DHCP supply of IP address to the TV adapter and made it trusted. But so far nothing helps. Just to be sure, I also did the same thing to the Defence+.
Can any other Comodo user (or the Comodo Support Team) tell me how to set up the firewall?
My setup:
Laptop with Intel® Core™ i5-2450M processor
Comodo Internet Security (free version)
Intel WiDi, version 3.0.13.0
TV adapter: Belkin Screencast, f/w 3.5.28.0
My guess would be you’re using the default firewall rules which only allow svchost - the service responsible for DHCP and most media related services - oubound. As a test, you could delete all the ‘Windows System Applications’ default firewall rule, change the firewall settings to Custom policy mode, possibly change alert frequency to high or very high (lots of alerts) and make sure you’re not blocking - apart from ICMP - inbound connections. Then see what happens when you connect to/from your TV. You can post the logs if you’re not sure.
First, there may be a slight problem with terminology. My Comodo is in Swedish and my wordings below may not be exactly the same as in the official English Comodo.
I am not very familiar with firewall settings and wasn´t sure how to follow your advice. You talk about default rules which I interpreted as being same as predefined rule (right or wrong?). I first noted that the existing Windows System Applications rule was already a custom rule (NOT a predefined rule) and then tried a number of different Custom rule settings (never mind which ones) and even deleted the Windows System Applications entry completely, but nothing helped. I then turned to Global Rules and found that one of the existing rules was following: “Block IP In from MAC Any to MAC Any Where Protocol is Any”. In view of what you said about “not blocking - apart from ICMP - inbound connections” that did not look too good. I started by making it simple and just switched from IP to ICMP to make it “Block ICMP In from MAC Any to MAC Any Where ICMP Message is Any”. This turned out to be completely successful, the WiDi connection was not blocked anymore.
So far so good, but I have some more questions before the case is closed for me.
First, this new rule seems to conflict with two other existing global rules. Currently I have “Allow ICMP In from MAC Any to MAC Any Where ICMP Message is Fragmentation Needed” and “Allow ICMP In from MAC Any to MAC Any Where ICMP Message is Time Exceeded”. What should I do? How do you suggest I leave the Global Rule section?
Secondly, after all trial and error settings I made of the Windows System Applications Rule I am not sure I remember what it was like when I started. What should it normally be?
Unfortunately, not having access to one of these WiDi devices it’s down to best guess. However, most of these types of device need inbound connections, which the firewall tends to block, one way or the other. By removing the Block IP in rule and the Windows System Application rule, you’ve effectively allowed the inbound connections. Now, however, you need to make sure you haven’t left your firewall open. To that end, it may be a good idea to post some screen shots of your firewall rules - Application and Global, as well as the firewall logs.
So far so good, but I have some more questions before the case is closed for me.
First, this new rule seems to conflict with two other existing global rules. Currently I have “Allow ICMP In from MAC Any to MAC Any Where ICMP Message is Fragmentation Needed” and “Allow ICMP In from MAC Any to MAC Any Where ICMP Message is Time Exceeded”. What should I do? How do you suggest I leave the Global Rule section?
The rule in it’s current state is really not needed. What we’d want to do, ultimately, is restore the default block IP rule, but before we can do that we’ll need to create some allow rules for the WiDi above this.
Secondly, after all trial and error settings I made of the Windows System Applications Rule I am not sure I remember what it was like when I started. What should it normally be?
The default Windows System Application rule - default, in that it’s created when you install CIS - has a very simple rule, but as with the Global IP Block, we’ll probably need to make some changes.
Please post the details requested above and hopefully we can make some progress.
I have uploaded the Application and Global screen shots as you requested.
Some notes on the Application screen:
The first 4 entries are various WiDi exe files that I added myself. I have tried a lot of different settings, the settings you see now just happen to be the last ones in force when I turned my efforts to the Global Rules.
You will also find an entry for Windows System Application, because, after completing the successful Global Rules exercise, I reintroduced it again, using the custom policy option Copied From … “Windows System Application”. But I still don´t think this is what I had initially.
Regarding the logs, it is a bit strange, but there are no entries in the firewall log for the last week even though I made a lot of connection attempts with various settings and I had warnings enabled (first Medium level, then Maximum). For the complete period from August last year there are entries related to WiDi on 2 occasions, 1st when I first used WiDi, 2nd after installing an update to the Widi software. I will give you the log anyway, but I don´t think it is of much use.
Without actually being able to play with one of these and basing my suggestions off of your screen shots, this is what I’d do.
Global rules:
The first thing I’d do, is identify which of the four network zones you have defined, that relates to your home network, possibly something like 192.168.0.0/255.255.255.0 and change the name so it’s easily identifiable. If you don’t need the other zone rules, remove them and leave the two rules for the home network at the top. Having done that, I’d revert the final rule to it’s former IP Block in with logging (you can turn logging off if you find the logs become to busy)
Making the aforementioned changes will allow the necessary connections between your PC and other devices on your LAN and will block anything you don’t want.
Application rules:
A little more difficult, but for simplicity, if things are working correctly, leave them as they are, with one exception, remove the rile for all applications just below the WiDi rules.
If you wanted to ‘tighten things up’ you could change the WiDi rules so that the communication is only allowed on the LAN.
Thanks for all help so far.
Identifying which network is my home network was easy, understanding the others not quite so easy. I think one of them is the WiDi subnetwork after receiving a DHCP IP address, another one has a link-local IP type address – could it be WiDi waiting for/not having received a DHDCP address? Changing the name of the home network, originally called Hemma #1 was easy in the Network Zones window. I called it Hemma LAN, deleted the two networks I thought irrelevant, as you suggested and was left with Hemma LAN and Hemma #2. But then came a surprise. One of the deleted networks reappeared during an exercise to enable WiDi and had been called Hemma #1 as the system believed #1 was now available. But when I checked the Global rules I found that the name change was not visible there and I have now 2 sets of rules for networks with the same name, Hemma #1. Seems like a Comodo bug to me.
What I couldn´t understand is how reverting to the previous IP in blocking would help, except that logging might help identifying the details of what blocks WiDi. And it did! WiDi stopped working again as I feared and the log showed what had happened: UDP IN had been blocked for Windows Operating System, Source IP 0.0.0.0, Port 68, Target IP 255.255.255, Port 67.
So, I then tried a new Global rule: “Allow UDP In from MAC Any to MAC Any Where Source Port is 68 and Target Port is 67”. Then WiDi got its IP address and worked again, but I don´t know if I have opened up for other problems. Is it OK to leave it like that?
One thing more has happened since I made this. I am receiving a series of log entries relating to Windows\System32\svchost.exe, UDP in is being blocked for source IP (=my NAS), various ports to target IP (=my PC), port 59290. It seems these events appear two at a time every 20 minutes, always with different source ports. I don´t understand what is being blocked, but I can still see the NAS on the Explorer and it seems I can stream media contents. I haven´t done anything to change any settings of the NAS. Should I assume this was going on also in the past, only didn´t see it until I enabled logging of IP in?
Do you have a wired and wireless connections? As far as the link local zone, it’s not uncommon for these to be found, it only takes one instance of the DHCP server responsible for your LAN to either not respond or respond too slowly. There’s no harm in leaving that zone, but it’s up to you if you want the corresponding rules.
Changing the name of the home network, originally called Hemma #1 was easy in the Network Zones window. I called it Hemma LAN, deleted the two networks I thought irrelevant, as you suggested and was left with Hemma LAN and Hemma #2. But then came a surprise. One of the deleted networks reappeared during an exercise to enable WiDi and had been called Hemma #1 as the system believed #1 was now available. But when I checked the Global rules I found that the name change was not visible there and I have now 2 sets of rules for networks with the same name, Hemma #1. Seems like a Comodo bug to me.
As fa as I remember, it used to be the case that if the zone name was changed, the change fed through to the rules, but from what I’ve seen recently, I’m not sure it that’s still the case. It’s something I need to look at.
What I couldn´t understand is how reverting to the previous IP in blocking would help, except that logging might help identifying the details of what blocks WiDi. And it did! WiDi stopped working again as I feared and the log showed what had happened: UDP IN had been blocked for Windows Operating System, Source IP 0.0.0.0, Port 68, Target IP 255.255.255, Port 67.
So, I then tried a new Global rule: “Allow UDP In from MAC Any to MAC Any Where Source Port is 68 and Target Port is 67”. Then WiDi got its IP address and worked again, but I don´t know if I have opened up for other problems. Is it OK to leave it like that?
Looking around the Intel site I found some relevant information. It appears that the Intel ‘My WiFi technology software’ includes DHCP, DNS and uses the address range 192.168.16.x which is probably different to your LAN range (192.168.1.x)? That being the case, to cater for the new network, you’ll have to do one of two things, either support two zones and two sets of zone rules or create discreet rules, as you have done for DHCP, expressly for WiDi. Once you have all the necessary rules enabled to support WiDi and your LAN, you can re-enable the block.
One thing more has happened since I made this. I am receiving a series of log entries relating to Windows\System32\svchost.exe, UDP in is being blocked for source IP (=my NAS), various ports to target IP (=my PC), port 59290. It seems these events appear two at a time every 20 minutes, always with different source ports. I don´t understand what is being blocked, but I can still see the NAS on the Explorer and it seems I can stream media contents. I haven´t done anything to change any settings of the NAS. Should I assume this was going on also in the past, only didn´t see it until I enabled logging of IP in?
I’d need a few more details such as the services related to that specific instance of svchost. there are various software applications you can use to acquire this information, such as Process Hacker or Process Explorer you can also use the following:
In an elevated command prompt type netstat -anob
Find the instance of svchost with the appropriate connection and make a note of the PID
Looking around the Intel site I found some relevant information. It appears that the Intel 'My WiFi technology software' includes DHCP, DNS and uses the address range 192.168.16.x which is probably different to your LAN range (192.168.1.x)? That being the case, to cater for the new network, you'll have to do one of two things, either support two zones and two sets of zone rules or create discreet rules, as you have done for DHCP, expressly for WiDi. Once you have all the necessary rules enabled to support WiDi and your LAN, you can re-enable the block.
Yes, 192.168.16.20 is the address for the network zone I have for WiDi.
Is the rule I introduced yesterday and still have in force "UDP IN blocked for Windows Operating System, Source IP 0.0.0.0, Port 68, Target IP 255.255.255, Port 67" such discreet rule you mentioned? If so, it would be easier to stay with that, if there are no disadvantages.
I'd need a few more details such as the services related to that specific instance of svchost. there are various software applications you can use to acquire this information, such as [url=http://processhacker.sourceforge.net/]Process Hacker[/url] or [url=http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx]Process Explorer[/url] you can also use the following:
In an elevated command prompt type netstat -anob
Find the instance of svchost with the appropriate connection and make a note of the PID
In the same command prompt type tasklist /svc
Find the PID noted above and list the services
Post here.
I found these services: FDResPub, FontCache, SSDPSRV, upnphost, wcncsvc