CFP stopping aquiring automatic network address

I am using Internet connection sharing (ICS) with a server (XP home), connected to the internet using a wireless modem (I can’t use a router because of this), and a client (XP pro) using the server for ICS. I have spent a lot of time getting the ICS to work properly, until I found that it only worked if I used automatic ip addresses, not the static I have been using previously (for some reason this was necessary only for ICS, file and printer sharing worked and I could ping between them, but not connect from client to internet).

This works fine if the server is started first, but if the client (my wife) starts before the server, the network won’t work. The client seems to get (make itself?) an ip outside the trusted interval 192.168.0.1-255. When I try to repair the network, it seems like Comodo is blocking the client, and stops the server from assigning a proper ip to the client. If I turn Comodo off I can repair and then I can turn it on and use ICS.

Does this seem like a possible explanation? Any idea how to make this work without turning Comodo off? Is there a way to force the client to take an automatic ip within the trusted interval. As I wrote, if i give it a static address, ICS fails.

Welcome to the forum medimus :slight_smile:

One of the problems with ICS under Windows XP, is that it cannot use statics addresses. Once you configure the ICS server, it will automatically set it’s self up as a DHCP server for the internal LAN, with an address of 192.168.0.1. Each of your ICS configured clients will then try to contact this server to aquire an IP Address in the 192.168… range.

If the server is unavailable when a client starts, it will be unable to aquire an address and will revert to APIPA (Automatic Private IP Addressing) This will give the client and address in the range:
169.254.0.0 to 169.254.255.255.

Assuming you have created a trused zone in CFP with a range of address to support ICS (192.168.0.0 to 192.168.255.255) The client will be blocked by CFP as the 169 address is unknown.

There are a number of FAQ’s on the subject:

Dialup Router

Internet Connection Sharing

Also Microsofts official config page:

Another useful link:

http://www.microsoft.com/windowsxp/using/networking/expert/crawford_02july01.mspx

Hope this helps

Toggie

Hi Toggie,

All the threads, either referenced in your thread or on the Links to FAQ, that deals with ICS DHCP server assigning a new client joining either goes cold or solution are not posted publicly.

I am in the same situation and everytime a new PC joins my network i have to either assign a fixed IP address (bad practice) or “Allow All” to allow automatic assignment then move dial back to “Custom” to resume protection - i think it is time COMODO comes out with a public solutions. I am running v2.4.19.185. Can’t upgrade because i have CFP on W2K3 which is not support at present.

I have a network rule that allows UDP any IP for 67-68 (source and destination) IN/OUT and it is just above the default blocking rule, I have placed it at number 1 still did’t work.

Thanks

Acton140
(:SAD)

I have tried to allow the range 169.254.0.0 to 169.254.255.255 in Comodo (to let the un-assigned client get through to have a new network address) but it doesn’t work. To repair the network connection I have to set Comodo on the server temporarily to Allow all. Then it works.

In the links (I could read them all, action 140!), it says you can assign a static address to the client, but it doesn’t work - when I do that I’m rid of the internal network connection problem (when I start the client before the server), but internet connection sharing doesn’t work any more.

Medimus,

Yes, i could only get a new client connected to the network that serves internet through ICS when i assign a staic IP address or if, like you, “Allow All” then issue a “IPCONFIG /renew” from the client PC then and only then can i get my DHCP server to issue an IP address.

I spent 2 days going over similar posts and tried out replies from very experienced COMODO users/moderators but non have worked. It is very surprising that non the COMODO staff didn’t join in the discussion for similar posts perhaps they know something we obviously don’t !

I can only conclude that this is a known flaw (or bug) with CFP 2.x and COMODO knows it. So we will have to live with it or try something else.

It is just ashame that a good product like this can get a this little but fixed !

AND my name is Acton140 not “Action 140”

(:AGY)

Acton140

Sorry about the name acton (English is not my language, easy to miss words. I’m also sorry to say that I changed from Zone Alarm to Comodo because of this problem, it was the same problem there. I hope some Comodo team members will solve this issue, the firewall has worked very well in other aspects as far as I’m concerned.