The rule lists port 67 as the destination; should be 68 (that is, on the Host computer, since it’s an Inbound rule). Having 255.255.255.255 as the IP is fine; once the DHCP updates, the Net Mon moves on and applies the appropriate rule. Given the scenario of connecting from the 0.0.0.0 IP, I would suggest the following:
Allow UDP In, Source (the client) 0.0.0.0, Destination (the host) 255.255.255.255, Source Port (client) 67, Destination Port (host) 68.
This is exactly the opposite of the rule in place on my system to allow retrieval of the DHCP lease; remembering that Source and Destination change relative to the direction of traffic…
All that you want to do is be able to establish the connection to get the IP updated, etc. From there your LAN rules kick in.
LM
PS: Birdman, feel free to start a new topic about the security questions…
Now I’ve been confused before it wouldn’t surprise me to be wrong this time but the fact that it was working (at least part of the way) tells me 67 is correct.
Regarding the 255.255.255.255 would not the server in the DHCP discovery message tell the client its address, and would not the client communicate on that address vs. 255.255.255.255 when it make the DHCP request? I think another handshake takes place in order to get the IP assigned before moving on to the Network Monitor rules. Jake 77 you can confirm this in your wireshark log. What is the address for the DHCP request you mentioned in reply #6 ?
Birdman is right. The ports need to be the opposite. Client 68, host 67. When configured like that, I can see in wireshark dump that it goes further.
I’m attaching here also screencaps from success case (firewall in allow all state) and fail case from wireshark. At least you can see the used ip’s and the message flow there.
Birdman, yes I see you are correct. TNX for the informative article. Client will use 67 In and Out; Host/Server will use 68 In and Out.
As it is obvious to me (:TNG) that Birdman is more knowledgeable in this area, I’m going to step back (as gracefully as possible) on the details of the DCHP Lease renewal (at least for the moment… perhaps there will be a better opportunity for me to embarrass myself later) ;D .
Reading the article it’s not clear to me why it’s getting stopped. Although, Jake, do you have any log entries in CFP now, with that rule? What if you set your LAN rules to Log as well; maybe that will log the missing response… If there are no log entries, you might go to Security/Advanced/Miscellaneous, and move the Alert Frequency slider to High or Very High, OK, and reboot. Then you should see some more detailed popups about allowing svchost.exe connections, etc. Perhaps you’ll be able to allow it by selecting “Remember” and Allow.
From my knowledge of CFP, either something is blocked, or something is wrong… For the “something is wrong” part, you might have the issue of traces of previous firewall (I suggest checking with a registry cleaner, such as RegSeeker). If not, you might uninstall/reinstall CFP; sometimes something goes wrong (small things) with install that create odd problems. Be sure to disable/turn off any active antivirus, antispyware, or HIPS prior to reinstalling the firewall (if you go that route).
Well unfortunately we’re just about at the end of my knowledge …
Jake77, another thing to look at. Rather than Allow All to get things to work can you separately disable the Network Monitor to see if you can serve an address when this is turned off ?
I didn’t have a problem until I got rid of the default TCP/UDP Out Any/Any rule; I changed it to some tighter scenarios. Then I started having problems with no connection when I rebooted, and couldn’t repair it either. Once I created the rule I mentioned, no problem since.
So here’s what I’m wondering… (worth a shot; won’t hurt anything) move Rule ID 3 (the TCP/UDP Out rule) up above the UDP In rule for the DHCP; in fact, move it to the top position (rule id 0). then reboot and see what happens. Perhaps if that has precedence, that will help the return side of the deal…
I’m not sure if you are still interested in this, but it looks like I’ve found a solution.
I set up cpf on the CLIENT to enable UDP In/Out for 0.0.0.0:68 (source) and 255.255.255.255:67 (destination).
I also configured the DHCP SERVER to enable UDP In/Out for 0.0.0.0:68 (source) and 255.255.255.255:67 (destination), but I had to enable UDP In on the SERVER for the last IP address of my desired network on port 137. My DHCP server assigns an IP like 192.168.0.x, so I had to allow UDP In from any 192.168.0.x:137 to 192.168.0.255:137.
Well that Port 137 info is interesting. Setting up a trusted zone on the server PC would also have solved the problem but its nice to know what explicitly was missing. I’m also interested as to whether or not this works for others trying to use DHCP with ICS.
Yes, I am using it with ICS. I must admit, my DHCP server is my home computer running ICS… 88)
About that port 137: I have already set up my local area network addresses as a trusted zone both on my ICS server and my ICS client computer, but DHCP did not work until I explicitly created that rule. (I figured it out looking at the activity/connections list while the network control rules were turned off.
Okay I stand corrected. I had meant to ask how you discovered this. I used the same method for determining that I needed an explicit outbound rule to allow 255.255.255.255:67 in order to get an IP from my router/DHCP server (I was tightening up my outbound rules at the time).
Cool.
Standing by to hear how others (Fred H. , Jake77) do.
Taking my laptop to my office and back home, I must admit, my solution is still not perfect. My client computer still does not get dhcp sometimes. But if the client does get the DHCP once, it has no problems getting it again with IPCONFIG /RELEASE and IPCONFIG /RENEW.
I don’t know what is missig.
Yes, it is very strange.
Unfortunately CPF never logs anything, but I get this entry in the system log:
[i]Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 000AE4BAC9A8. The following error occurred:
The semaphore timeout period has expired. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.
Sorry for being away quite a long time, but I have not had the time to test this.
However now I had some time to run some tests. I tried making a new installation of xp to a separate hd, and installing and configuring cpf. However the results were the same… not working… So I guess it is not about the registry.
Thanks for the tip CobrAttila
I created 2 rules (hopefully they are correct):
rule 0 : allow udp in from ip range: 192.168.0.0-192.168.0.255 to ip 192.168.0.255 where source port is 137 and destination port is 137
rule 1 : allow udp in or out from ip 0.0.0.0 to ip 255.255.255.255 where source port is 68 and destination port is 67
After creating the rules, I rebooted the ics pc. My client(s) do not have a firewall installed.
But unfortunately, this did not do the trick for me Still not working. According to the wireshark dump, it goes as far as earlier, dhcp discover(client to ics pc) → dhcp offer(ics pc to client) → 5 x dhcp request(client to ics pc), then back to dhcp discover again (client to ics pc).
When comparing the dhcp discover and dhcp request, the source and destination addresses and ports are exactly the same. So if the initial dhcp discover message gets through the firewall, then I can’t see no reason why the dhcp request would not get past the firewall as well.
Also there was this earlier post by birdman, to turn of the network monitor to see if it works then. I tried that, and dhcp seemed to work fine when the network monitor rules were off.
This seems to be a tricky one to solve (at least in my case), but thank you all for the tips and support so far :■■■■
Sorry to say, but turning off Do Protocol Analysis did not solve the problem.
Strangely when my client comuter suceeds in getting a DHCP address once, it can get it again without any problem using IPCONFIG /RELEASE and IPCONFIG /RENEW commands, even with CPF on on both computers.
I’m still about to see if I can get a better view on this whole matter with WireShark…
Little Mac, did you (can you?) ask the developers about this matter yet? Maybe they know something we don’t…
to Jake77:
I am very sorry about my solution not working for you, but in the end it did not really work for me either.
to Little Mac:
Thank you for your prompt reply!
Let me tell you more about my computers and the networks I connect to.
I have a LAN connection in my office and another LAN at home. I have a notebook I use on both networks. My notebook is configured to be a DHCP client. In my office the DHCP service and the internet access is handled by a hardware router/firewall combo. It assigns an IP from the 192.168.1.x range. I never had any problems with getting an IP address or accessing the internet my office, so I itt looks like CPF does not interfere with DHCP on my client computer.
My other computer is a desktop computer configured to be an ICS server at home, with a software firewall set up here. Microsoft made it’s ICS server in Windows XP to always use the IP 192.168.0.1. So my desktop computer is always configured to have the same IP. The clients should get some IP form the 192.168.0.x range. It did work fine until I dumped my old firewall and switched to CPF. My desktop computer was just reinstalled from the ground up two weeks ago, with CPF being my firewall.
Now to answer you question: I usually turn off both my desktop and notebook computer before I leave, and I turn them back on one by one when I get home, so they are almost always freshly started. Sometimes I succeed in getting an IP at home, sometimes I don’t. But, and it’s very interesting, when I finally get one, I seem to be able to always get it again (even after I turn off and restart both my computers) until I take my notebook to my office again. Then the whole problem starts anew.
I played with CPF until my notebook got the IP from my desktop computer. Then I read your post and did as you asked and shut down both computers. Then I restarted my desktop first, and my notebook later. I had no problem getting the IP now. I believe everything will be fine until I go to work tomorrow…
I hope I have answered you question with this little novel…
Okay, so what are the Network Rules, Application Rules, Alert Frequency (and other “Advanced” config settings) for CFP at the home Desktop PC?
Compare to Laptop for Work.
If Laptop at work is getting DHCP renewal, then all is good there. If Desktop at home is only getting DHCP renewal sometimes, then something is different. You assignment, should you choose to accept it, is to find out what is different.
Also, instead of using Desktop at home as a host, try connecting laptop directly to modem (I presume you’ve got a high-speed modem; cable, dsl, etc). How does it work? Try it several times. Do the whole ipconfig /release then repair the connection. See if works time after time without problem.
For the “something is wrong” part, you might have the issue of traces of previous firewall (I suggest checking with a registry cleaner, such as RegSeeker). If not, you might uninstall/reinstall CFP; sometimes something goes wrong (small things) with install that create odd problems. Be sure to disable/turn off any active antivirus, antispyware, or HIPS prior to reinstalling the firewall (if you go that route).
