DHCP blocked despite the "fixes" found here...help please!

Help for v2
#1

I have read every post through the forums for an answer to this and have tried many things suggested there with no help. I have allowed for access to DHCP used ports 67 and 68 incoming and outgoing. I have allowed access for 0.0.0.0 and 255.255.255.255 in and out. I have added a range of 192.168.0.1-192.168.0.255 for LAN. I have tried several of the other suggestions found here as well with no success. I have even tried making a rule to allow every kind of access from every port and every ip and placed them at the top of the list and my DHCP is still being blocked. Both services.exe and svchost.exe are allowed full access to the network.

The only thing that allows my DHCP to work correctly is to turn off the network monitor until an IP has been assigned. This is simply not viable to our use, but I would like to continue using Comodo if anyone can find a way to resolve this.

Thank you for your assistance in advance.

#2

In the “Tasks” menu, click “Scan for known applications”.

#3

This is a tcpdump of a Windows XP machine boot using DHCP. The lines are long, and they’re wrapping, which makes it a bit hard to read. The format is one line per network packet, of sending MAC > receiving MAC and descriptive detail.

00:11:11:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:11:dd:ee:ff, length: 300
00:01:02:aa:bb:cc > 00:11:11:dd:ee:ff, ethertype IPv4 (0x0800), length 342: 192.168.10.254.67 > 192.168.10.8.68: BOOTP/DHCP, Reply, length: 300
00:11:11:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.10.8 tell 192.168.10.8
00:11:11:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.10.8 tell 192.168.10.8
00:11:11:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.10.8 tell 192.168.10.8
00:11:11:dd:ee:ff > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.10.254 tell 192.168.10.8
00:01:02:aa:bb:cc > 00:11:11:dd:ee:ff, ethertype ARP (0x0806), length 42: arp reply 192.168.10.254 is-at 00:01:02:aa:bb:cc
00:11:11:dd:ee:ff > 00:01:02:aa:bb:cc, ethertype IPv4 (0x0800), length 76: 192.168.10.8.1025 > 192.168.12.16.53: 58049+ A? time.windows.com. (34)
00:01:02:aa:bb:cc > 00:11:11:dd:ee:ff, ethertype IPv4 (0x0800), length 414: 192.168.12.16.53 > 192.168.10.8.1025: 58049 2/8/8 CNAME[|domain]
00:11:11:dd:ee:ff > 00:01:02:aa:bb:cc, ethertype IPv4 (0x0800), length 90: 192.168.10.8.123 > 207.46.130.100.123: NTPv3, Client, length 48

Who’s who, and what’s going on:

Booting machine: MAC 00:11:11:dd:ee:ff gets assigned 192.168.10.8
DHCP server : MAC 00:01:02:aa:bb:cc at IP address 192.168.10.254

The booting machine asks the DHCP server for an IP address. The DHCP server answers the query, and the IP address of the recipient is the assigned IP address. The booting machine then queries the LAN for conflicting addresses (those 3 arp queries), and getting no answers, keeps the IP address. Then it does the standard time query, and all is up and running.

Problems can occur in two places: something is blocking an application, or something is blocking the initial DHCP request to 255.255.255.255. Bridged LANs, including many wireless setups, don’t do broadcast traffic (MAC ff:ff:ff:ff:ff:ff ) without some special handling.

A real quick reality check may be in order. What shows in the CFP logs (Activity → Logs), and without CFP running, what address to you get assigned? Is that address block in your CFP rules? Microsoft ICS uses 192.168.0.x, Linksys routers use 192.168.1.x, Belkins use 192.168.2.x, and I’ve seen some at 192.168.254.x. (3Com, I think)

#4

I scanned for known applications first thing on install…it is not a problem with the application list. Enabled or disabled the application monitor has no impact on the assignment of an address.

What shows in the CFP logs (Activity → Logs) - Nothing shows, no alerts. It just won’t allow DHCP to work properly unless I disable the Network Monitor.

and without CFP running, what address to you get assigned? - 192.168.0.X, as normal the last number varies from time to time. Last connection was .72.

Is that address block in your CFP rules? - No that address is not blocked, in fact like I mentioned above, when I allow every possible IP address and Port Comodo still blocks DHCP. The only thing that allows DCHP to function correctly is to exit Comodo or turn off the Network Monitor.

Thank you for the suggestions and help, hopefully someone can find out what is happening here.

#5

Curiouser and curiouser…

Let’s check a couple of settings in CFP. Go to Security → Advanced, Advanced Attack Detection → Configure, and then the Miscellaneous tab. Make sure the first checkbox of “Block all outgoing while booting” is cleared.

Next is to check the order of the rules in Network Monitor. Rules are processed in numeric order, starting at rule 0, and continuing to the bottom of the page. First matching rule wins, and processing rules stops at that point. The DHCP address assignment uses the UDP protocol, which is part of the IP protocol. If the rules are somehow out of sequence, or don’t have the protocols right, things can get strange. If you’re not sure of the rules, or just want a confirmation, you can make a screenshot, and post that screenshot here.

If all that seems to be okay, then there are some more things to try, but that’s for later.

#6

Make sure the first checkbox of “Block all outgoing while booting” is cleared. - It is.


Next is to check the order of the rules in Network Monitor. - The order is as it should be to the best of my knowledge, according to all the posts I’ve read about this problem. #0 and #1 are both allowing the UDP in and out for ports 67 and 68. This is followed by rule #3 and #4 allowing access to the full range of local addresses (192.168.0.1-192.168.0.255). The rest of the rules I currently have loaded are the default rules from install in the default order. I have removed some of the rules I had previously tried since they had no effect, such as allowing in/out to 0.0.0.0 and 255.255.255.255 as had been suggested by some.

When I tried out of curiosity to open all ports and IP I created those rules at the top of the list as well, though even with everything allowed I could not get a DHCP connection until the network monitor was turned off again. It seems to me rules allowing everything would have the same effect as turning off the monitor, but that isn’t the case for some reason. This doesn’t seem to follow any logical course that I can see.

#7

Now that is strange. You’re correct, a rule 0 of “allow protocol IP in&out from any to any” is effectively the same thing as turning off the Network Monitor. That rule 0 should pass all traffic always.

Based on your description, I’m making a guess that there is something left over in the Windows TCP/IP stack. One of the Windows updates back around SP2 provided a command to reset the protocol stack. Just to kind of clean house a little, run this from a command prompt.

netsh winsock reset

You probably should reboot, and you may have to reinstall CFP, depending on how thoroughly the cleaning is. Better yet, uninstall CFP first, then that netsh reset, reboot, and reinstall CFP. A bunch of work, and it may not do anything, but there will be a clean TCP/IP stack.

And keep the rule 0 to allow all traffic for the time being. It’ll confirm that CFP is installed, and isn’t, or rather shouldn’t, be doing anything.

#8

Unfortunately this didn’t help the situation. I uninstalled and cleared the TCP/IP stack as you suggested.

Thanks for all the help so far, any other suggestions?

#9

CFP should still be running with rule 0 as the allow all from all, which should take CFP out of the picture. Should, and does, are sometimes different things, speaking from experience.

The next step is to see what is happening on the wire. Are the packets that are supposed to be there, really there? That means installing a packet sniffer.

One for Windows machines, is Wireshark, available for download thru wireshark.org ( not .com, be careful what you type). Install it into its default location (c:\program files\wireshark\ ), and it will give a packet-by-packet trace of what is coming and going to your machine.

Onec installed, from a command prompt, you can run “ipconfig /renew” and go thru a DHCP operation, although not exactly like a DHCP done at boot time. Watch that happen in Wireshark, and compare to the Network Monitor rules, still with rule 0 as an " allow all". If that DHCP seems to hang, then exit CFP, and do the “ipconfig /renew” again. The details in the DHCP request and reply are probably where the problem is. Won’t know for certain until we see the details.

I’m coming up on the end of my day, so I’ll have to pick this up again later. Wireshark should tell a lot about what is actually happening, rather than having to make assumptions and try things from there.

#10

Bob, is this how your rules are written? You should only need to have the first rule to get an IP address from the DHCP server.

Example: (place the rules at the very top of your Network Monitor rules list)

[b]ALLOW-check the checkbox to log
OUT
UDP
Source Address: 0.0.0.0
Destination Address: 255.255.255.255
Source Port: 68
Destination Port: 67

ALLOW-check the checkbox to log
IN
UDP
Source Address: 0.0.0.0
Destination Address: 255.255.255.255
Source Port: 68
Destination Port: 67[/b]

jasper

#11

Almost the right rules. If you compare to the tcpdump output a little further up, you’ll see the typical DHCP handshake. One thing though to keep in mind, is that a broadcast address should never be a source address. Get the right combination, and it’s possible to crash an LAN. The DHCP response comes from a server with a real IP address, and the Network Monitor rules have to be set to allow that address to come thru.

#12

So the correct rules woiuld be;

ALLOW-check the checkbox to log
OUT
UDP
Source Address: 0.0.0.0
Destination Address: 255.255.255.255
Source Port: 68
Destination Port: 67

ALLOW-check the checkbox to log
IN
UDP
Source Address: DEFINITIVE ADDRESS OF DHCP SERVER
Destination Address: 0.0.0.0
Source Port: 67
Destination Port: 68

Correct?

Ewen :slight_smile:

#13

Sorry guys I had dyslexia there. I looked at my post and didn’t see what you were talking about and I was looking straight at it. I thought about it for a bit and then went OMG! I just had Bob set up a loop from H#LL!

Sorry Bob, I changed my post and it is correct now.

jasper

#14

If you ever get the chance to look at raw unfiltered traffic from the Internet, you’ll see a lot of things that really aren’t supposed to ever ever happen. That’s why there are firewalls. :smiley:

DHCP reply packet. Almost right…

The sequence goes something like this:

A machine boots up, and has no idea of its IP address. It’s Ethernet NIC does have a MAC address wired into it. So the machine puts together a packet as best it can. Not knowing its own IP address, it says instead “I’m 0.0.0.0”. Not knowing any other machine, its asks the LAN segment “hey, anybody, 255.255.255.255”, tell me who I am “port 67, DHCP request”. That made up packet goes out with the MAC address, to the LAN anybody MAC ff:ff:ff:ff:ff:ff.

Somewhere out on that LAN segment, is a DHCP server. It sees the plaintive port 68 request from an amnesia host (0.0.0.0) asking for help (255.255.255.255). The request came from a given MAC address.

The DHCP server checks its tables, and selects an address, say 192.168.0.72 in this instance. It puts together a reply packet, Ethernet addressed to that MAC. In that reply packet, the server introduces itself (Hi, I’m 192.168.0.1), and calls the host by name (and you are 192.168.0.72). The host knows that it now has a name, as the reply came from port 68, DHCP reply, and was addressed to its MAC.

Oh, I’m 192.168.0.72, because this packet came in to my NIC, and said that I was 192.168.0.72. I’ll check, just to make sure, by calling out for 192.168.0.72 (ARP query 3 times). If I don’t get an answer, then my name really is 192.168.0.72.

The request reply is the actual assignment of the IP address. You don’t know for certain what you’re going to get back, other than it should be within the range for that LAN segment.

That’s a bit of an explanation for the tcpdump listing near the beginning of the topic. Getting the request, and the reply, rules correct is fairly straightforward. The 0.0.0.0 and the 255.255.255.255 are special case addresses, and have a very limited context in DHCP request packets.

#15

You are absolutely correct about the order of how things go and I have seen a few sniffer logs, but, you are only monitoring 1 interface. All you are seeing is what is on the interface that you tell it to monitor. I have seen where WinXP will try and send out the same request on a VPN connection, if the service is running, and it will show as an “inbound packet” in the log on a firewall that can see it.

I don’t believe that version 2.4 of the Comodo firewall monitors the 0.0.0.0-255.255.255.255 connections as refined as other firewalls do, JeticoV2 does log all of the interfaces for any traffic, whether it is allowed or not and whether it is dead or alive, if you set it that way.

What I was trying to find out was whether there was a VPN program possibly interfering with the outbound attempts to connect or not. I have only seen a VPN cause trouble a couple of times on DHCP connection attempts. I don’t know why but it has happened in the past. WinXP has tried to grab the VPN interface instead of the live interface. Normally this inbound packet won’t interfere with DHCP but it can alert you if you are having trouble.

The way I had the second rule set at first was totally wrong but the way I have it now will not affect anything and is a “just-in-case” rule.

Sorry for hijacking your thread BobThompson.

jasper

#16

Morning All!

I too have been struggling with this DHCP problem for some time.

Thanks to the great advice in this topic, I installed wireshark, and set about to solve the problem.

I did not make it yet.

Using my XP2 Pro desktop system and ICS to share internet traffic. When I turn on my notebook, connected to the Desktop via a wireless router and the desktop Comodo in custom mode, I cannot get an IP address. Switch Comodo to Allow all, and I get an address fine.

I installed a pass all rule 0 in the network monitor, reset Comodo to Custom, turned on Wireshark, and did a repair connection on the notebook, and watched…

Here is what I saw:

53 60.905185 Agere_34:ac:b4 Broadcast LLC
54 64.322961 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x9e6646ca
55 64.326725 SmcNetwo_06:96:6f Broadcast ARP Who has 192.168.0.122? Tell 192.168.0.1
56 64.334990 192.168.0.1 255.255.255.255 DHCP DHCP Offer - Transaction ID 0x9e6646ca
57 64.339963 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x9e6646ca
57 64.339963 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x9e6646ca
58 67.343187 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x9e6646ca
59 74.343328 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x9e6646ca

Sorry about the line wrap…

As near I can tell, packets 53 and 54 come from the notebook, looking for an IP address from the DHCP server on the desktop. Packets 55 and 56 appear to be the desktop’s response offering an IP address… And there it sits. the remaining packets are repeated IP address requests to the desktop from the notebook. After four tries, the notebook reports failure to get an IP and quits.

So I conclude the outgoing DHCP offerings from the desktop are being trapped by Comodo somehow. It I turn off the network monitor, the packets exchanges continue fine and the notebook gets it’s IP address.

I run Comodo on the notebook too, so I thought the packets might be trapped there, so I removed Comodo on the notebook and no change.

Are there any ideas on other avenues I can try?

Dick

#17

Now that is interesting…

Standard request comes in, and the reply goes back to the LAN broadcast address??

Which makes for an obvious rule to try: allow UDP out to destination 255.255.255.255, since this PC is running as an ICS host and therefore as a DHCP server. The rule would look like this:

allow out protocol UDP from host 192.168.0.1 to host 255.255.255.255

The Wireshark data needs to show some additional information. That being the MAC addresses of the packets. In Wireshark, to show the MAC data, you need to Edit → Preferences, User Interface, Columns, and New two more columns: SrcMAC is format “hw src address (unresolved)”, and DstMAC is format “hw dest address (unresolved)”.

With that additional information, watching the DHCP request and offer should give some more insight as to what is happening. Wired Ethernet DHCP has the LAN broadcast address of 255.255.255.255 being used as the MAC broadcast address ff:ff:ff:ff:ff:ff.

I’m suspecting the DHCP Discover request will have the source MAC of the wireless router, in which case the router is doing a proxy arp. In which case, the 255.255.255.255 is going to have the MAC of the router. Then the router is bridging the packet back to the notebook.

#18

Ok, back with the computer and DHCP problem again, I’ve tried the other suggestion with no effect. Here is the Wireshark date, hopefully it will help. From what I can see everything that needs to be allowed has been already in the Network rules. Maybe you’ll see something I am not.

No.     Time           Source                Destination           Protocol Info    SrcMAC                DstMAC                SrcPort DstPort                                                        
      1 0.000000000    192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
      2 0.744940000    192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
      3 0.918295000    0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0xe1085209                       00:20:ed:6a:bc:d5     ff:ff:ff:ff:ff:ff     68      67
      4 0.920046000    Elitegro_70:c4:2a     Broadcast             ARP      Who has 192.168.0.54?  Tell 192.168.0.1                         00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff             
      5 1.494994000    192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
      6 1.652361000    192.168.0.1           255.255.255.255       DHCP     DHCP Offer    - Transaction ID 0xe1085209                       00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     67      68
      7 1.653303000    0.0.0.0               255.255.255.255       DHCP     DHCP Request  - Transaction ID 0xe1085209                       00:20:ed:6a:bc:d5     ff:ff:ff:ff:ff:ff     68      67
      8 4.649199000    0.0.0.0               255.255.255.255       DHCP     DHCP Request  - Transaction ID 0xe1085209                       00:20:ed:6a:bc:d5     ff:ff:ff:ff:ff:ff     68      67
      9 11.638976000   Elitegro_70:c4:2a     Broadcast             ARP      Who has 192.168.0.3?  Tell 192.168.0.1                          00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff             
     10 11.649871000   0.0.0.0               255.255.255.255       DHCP     DHCP Request  - Transaction ID 0xe1085209                       00:20:ed:6a:bc:d5     ff:ff:ff:ff:ff:ff     68      67
     11 13.844685000   192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
     12 14.589611000   192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
     13 15.339651000   192.168.0.1           192.168.0.255         NBNS     Name query NB POP3SERVER<00>                                    00:0d:87:70:c4:2a     ff:ff:ff:ff:ff:ff     137     137
     14 26.650714000   0.0.0.0               255.255.255.255       DHCP     DHCP Request  - Transaction ID 0xe1085209                       00:20:ed:6a:bc:d5     ff:ff:ff:ff:ff:ff     68      67

Thanks for all the suggestions and information so far, hopefully we can get this resolved since I’m not the only one with the problem.

[EDIT]

allow out protocol UDP from host 192.168.0.1 to host 255.255.255.255

Forgot to mention I had tried this rule you suggested as well with no help.

#19

Thanks for the response!

I tried your adjustments to the columns in Wireshark, and confirmed the true mac addresses of the packets - but no real change in behaviour.

Perhaps what I am trying to do may not be possible.

I’m using ICS on my desktop to share internet connections in my home. I added a wireless router to allow me to use wireless with my notebook.

I cannot get broadband here in my area, and using dialup on the desktop. I don’t think ICS will work without controlling DHCP. So I disabled DHCP in the wireless router, and changed the router address to 192.168.0.10 from its default 192.168.0.1 to allow the ICS desktop to have that address. So the desktop DHCP is providing IP addresses on the local network.

All works fine until Comodo get into the loop. If Network Monitoring is turned on, the notebook fails to get an IP. The notebook is connected wirelessly to the router which I presume passes on the DHCP request to the desktop for an IP. From the wireshark capture, it looks like the desktop got the request, and replied instantly with a proposed IP. I presume the IP goes to the router, and perhaps the router is not passing it on? But why would it work ok if Network Monitoring is turned off…

Perhaps I should just set a static address on the notebook, and forget about DHCP altogether. It works fine with static addresses…

Thanks for you comments.

I see the forum does not like my name, so will try another version of it…

Rick

#20

I’ll try not to get too terribly confused here.

rlebleu: Wireless DHCP is a known problem with wireless NIC chips. Setting a static address is the typical solution. You could separate your LAN into two parts, with ICS handling the address range from 192.168.0.1 up to something, say 192.168.0.127. And then configure your wireless router to be at 192.168.0.128, and have it act as a DHCP server for wireless clients, providing them with addresses of 192.168.0.129-192.168.0.254. ICS doesn’t know about that separation, so you could get an address assignment collision. Setting up a subnet is another option.

Bob: You’ve got something strange here, that looks like a hardware mismatch. These packets are following the DHCP protocol, but somehow aren’t connecting.

I checked the DHCP spec in RFC 2131 about the structure of frame 6 using the LAN broadcast address and broadcast MAC. It is correct. So the DHCP offer went out okay. The RFC says that the DHCP request that comes back should be a confirmation handshake, followed by a DHCP ACK. The detail in frame 7 will tell if the client actually saw the offer.

Some more Wireshark data is needed, for details about the DHCP packets. And only a very few packets, as this level of detail can generate tremendous amounts of stuff to wade thru.

Capture a DHCP transaction, like before. Right-click on the DHCP DISCOVER frame, and select “mark packet”. Do the same with the following DHCP OFFER and REQUEST packets. That will be maybe a total of 5 or 6 packets.

Then, from the Wireshark top line toolbar, select File → Print. Printer type is “plaintext”. Packet range is “marked packets only”. For the packet format, mark the checkbox for summary line and for details (but not the packet bytes, that’s a hexdump) For the packets details, buttonbox “all expanded”.

Output that to a file, and then attach that file to a posting here.

As the saying goes, the devil is in the details, and there are way way too many details here. This is starting to look like a hardware problem. And given the nature of the typical home hardware, we could likely find the cause of the problem, and not be able to make anything work because the hardware doesn’t have the settings.