Internet connection sharing - DHCP lease problem...

I have one machine running WinXP pro SP2 connected to internet with cable modem configured by DHCP, and have no problems obtaining address from my provider’s DHCP. However, when I plug in my wireless USB card, and enable internet connection sharing, I can not obtain DHCP lease from my computer which is running DHCP server now - unless I Allow All in Comodo Firewall. I tried to open DHCP ports 67 and 68 for UDP traffic, tried to allow svchost UDP traffic for these ports and UDP, but have not suceeded. What do I need to do to get my other machine which connects trough wireless get a lease without explicitely allowing all in Comodo?

Can you post your DHCP rule?

I find making a rule allowing UDP In/Out for Source Port 67-68, Dest Port 67-68, IP’s to Any’s, works.

If you’re trying to do ICS, you will likely need to create a Zone encompassing the two IPs, and use that Zone to Add a New Trusted network (both in Security/Tasks). This will create two rules in Network Monitor to allow unimpeded communication between the two. I realize this is probably what you’re trying to avoid. However, there’s more communication going on than just the DHCP via UDP on ports 67/68, and CFP will only allow communication that’s allowed. In order for ICS to work, the two systems have to be free to communicate.

LM

I’ve created the rules for trusted zone -192.168.0.x. All is working good if I allow all, allow my other machine to pick up the address, and again go to custom. I can’t get the machine to pick up the lease -will try rule above.

Edit: the rule to allow all UDP on 67-68 works. Thanks, pepoluan! :BNC
Edit 2: sorry, but it does not solve my problem… I’m stuck again with same trouble… ???

If switching to Allow All works, it’s an indication there’s a rules issue. When you did the Zone, did you then use the Zone to Define a Trusted Network? This should have added two rules to the top of the Network Monitor, positions Rule ID 0 & 1. The first will Allow IP Out from Any to Zone; the second will Allow IP In from Zone to Any.

If you have CFP on both machines (ie, Client and Host) you will need to create these same rules on both.

If it’s just on the Host, and it’s being blocked with those two rules at the top of the Network monitor, we’ll need to dig into the logs, most likely.

LM

One word of caution: Trusted Zones do not help DHCP.

Why? Let’s see:

Let’s assume that the Trusted Zone is for 192.168.0.0/24 (i.e. 192.168.0.1 ~ 192.168.0.255)

So defining a Trusted Zone puts two rules:

  • Allow IP To:Any From:192.168.0.0/24
  • Allow IP To:192.168.0.0/24 From:Any

A DHCP client has no IP address, yet. So it will send a broadcast IP packet like this:

Source: 0.0.0.0
Dest: 255.255.255.255

which the DHCP server will reply with an IP packet like this:

Source:
Dest: 255.255.255.255

The server’s response matches the 2nd rule of the Trusted Zone.

But the client’s broadcast packet does not match any rule of the Trusted Zone’s.

Which is why I think CFP really needs an interface-based rule.

I’ve made some notes (in colored text)

Re: The blue-colored question.

No. On bootup, the DHCP client has no knowledge whatsoever about the network. In other words, it cannot possibly know the address of the DHCP server. So, the client just send a packet to broadcast (Dest: 255.255.255.255) in the hope that a DHCP server picks it up and responds.

It is different if the DHCP client is renewing instead of asking for initial configuration. In this case, the client already knows the address of the server, which is the server that responds to the client’s initial request. So the client, out of politeness, send its renewal request directly to the server instead of bugging all the other stations in the network with a broadcast.

In addition, let’s remember that the DHCP request packet – in respect to the DHCP server, which in this case is the ICS-providing system – is an inbound packet, i.e.:

  • IP In
  • From 0.0.0.0
  • To 255.255.255.255

So the out rule has no saying on this matter.

Also, the server’s reply is outbound, i.e.:

  • IP Out
  • From
  • To 255.255.255.255

This is not covered by the IP Out rule.

Remember: The Original Poster says that his/her computer is the DHCP server (i.e. ICS-providing system), and other computers can’t get IP Addresses from his/her computer.

Okay, makes sense. However, one of the default Network rules is to Allow UDP Out from Any IP to Any IP on Any Port. Provided that the user has not set CFP to Block Outgoing Connection on Boot, would this not allow that “blind” DHCP query.

As to the Inbound response with no Header thus making it “unsolicited” I still think we may be dealing with the Inspection side of the firewall engine. But that aside, How much of this exchange happens before login? How would we then be able to obtain our lease?

What do you mean by “interface-based rule”?

LM

The OP’s problem was, his/her DHCP server (i.e. the ICS-provider) would no longer service DHCP requests from other computers.

I think I made you misunderstood: CFP’s Trusted Zone helps DHCP Clients. It does not help DHCP servers. Sorry, my bad.

So, from the server’s point of view, there are two packets that are not covered by the Trusted Zone rules:

  • IP In (received from DHCP client)

    • Source: 0.0.0.0
    • Dest: 255.255.255.255
  • IP Out (response to DHCP client)

    • Source:
    • Dest: 255.255.255.255

Um, no header? What do you mean no header?

What I meant: In addition to the IP-based rules, there should be an interface-based rule. For example:

Assume that I have 2 LAN cards:

  • 1 LAN card is connected to the Cable Modem, let’s say LAN Card #1
  • 1 LAN card is connected to the Internal Network, let’s say LAN Card #2

I want to allow all traffic going in/out of LAN Card #2, regardless of their IP’s, protocols, ports, whathaveyous.

Traffic via LAN Card #1 I regulate in the usual way, using IP’s, protocols, and ports.

Thus with one single rule, e.g. Allow In/Out of LAN Card #1, I replace all the Trusted Zone rules, and also allows non-addressed communication like the DHCP transaction.

Um, have we not discussed before about UDP not having an ACK response in the header, thus identifying it as an inbound “response” to the previous outbound request? TCP does, UDP does not… I think I remember the info correctly; there is, however, a possibility that I have misremembered the “who” of the conversation. If so, my apologies to Mr. Cisco… :wink:

LM

Ahhh, you mean no ACK :slight_smile:

Well, the DHCP conversation is very simple:

Client:67 <–> Server:68

(I may mix up the port numbers above, CMIIW)

Even if the IP address is 0.0.0.0 and 255.255.255.255, UDP still has its port number. I just left them out above.

So the conversation goes like this:

Client (0.0.0.0):67 → DHCP Discover → Broadcast (255.255.255.255):68

One or more DHCP servers listening on port 68 will pick up the broadcast, and it (they) will reply:

Server ( <Server’s address> ):68 → DHCP Offer → Broadcast (255.255.255.255):67

Client listening for replies on port 67 will pick up the broadcast(s), chooses one, and replies:

Client ( <Client address, given through DHCP Offer> ):67 → DHCP Select → Server ( <Server’s address> ):68

The DHCP Offer contains the Client’s address assigned by the DHCP Server.

So, in the lack of Interface-based rules, you must allow at least (on the server):

  • UDP In
    • From: Any IP, port 67
    • To: Any IP, port 68
  • UDP Out
    • From: <Server’s address>, port 68
    • To: Any IP, port 67

If the server is configured like this:

[Internal Net] – [Server] – [Cable ISP]

it means that, on the Internal Net, the Server has a static IP. On the Cable side, it gets its IP via DHCP from Cable ISP. In this case, two additional rules must be defined:

  • UDP Out
    • From: Any, port 67
    • To: Any, port 68
  • UDP In
    • From: Any, port 68
    • To: Any, port 67

We can merge these 4 rules into one:

  • UDP In/Out
    • From: Any, ports 67-68
    • To: Any, ports 67-68

Well, I hate to bring this up, but seems that rule does not help 100% - if a machine allready has an adress, it will be able to renew it, but when lease expires, it is unable to get new address from server… So running trough pepoulan’s posts, I think that this is the case when DHCP client knows the server address, and sends package directly to it. I added a rule Allow UPD In/Out from Any to Any on ports 67-67, both source and destination. But the problem still persists… Maybe some of Comodo’s traffic analysis is blocking the packets?

Rasha,

Try changing the network monitor rule on your server PC to Allow UDP In, Source Address Any, Source Port 68, Destination Address Any. Destination Port 67.

Pepoluan,

Your explanation is correct but you did have the port numbers reversed. Client uses port 68, Server/host uses Port 67 for DHCP discover, offer, request and Ack.

As far as the DHCP Ack going to address 255.255.255.255 this should not be a problem for the client as the Source (server) address is part of the trusted zone. This also assumes that no tightening of the outbound rule for the server has occurred (still IP Out Any).

AJB

AJB

I will try, but I’ve already allowed both ports for communication. When a lease should be acquired, i see that svchost.exe makes UDP communication, 0.0.0.0 and 255.255.255.255 and ports 67 and 68. But no lease can be acquired unlass i Allow All. I have no rules for svchost.exe, since I did a reinstall, just ot test if I am doing something wrong. By the way, the card on local network is USB wireless, could that be a problem? (V)

Okay, this is strange. With my previous rule, it works on my system. Although yes the public interface is not a sometimes-on-sometimes-off connection. I’ll draw a summary:

[Internal LAN] – [Server 2003] – [ISP]

The server’s connection to the Internal LAN uses static IP of 192.168.0.1. The connection to ISP is via USB, through a Cable Modem, and the Public IP Address is DHCP-Assigned by the ISP. The Server 2003 uses RRAS to act as NAT server, not ICS.

I suggest this:

  1. Close the Internet Connection (e.g. unplug the USB Wireless thingy).

  2. Put this one rule as rule #0 (i.e. topmost):

    UDP In/Out Allow
    Source: IP Any, Port 67-68
    Dest: IP Any, Port 67-68
    [ x ] Log (Log if the rule fires)

  3. Clear the log

  4. Activate the Wireless connection

  5. Power up a client PC and let it try to acquire a DHCP address

  6. After the client PC failed, export the log to HTML

  7. Open the HTML in a web browser, select the text, and post it here.

This is my setup -
On my desktop computer, connecting to the internet is done trough cable modem, which is connected to my network card, cofigured by ISP DHCP. This connection is shared with ICS.
Local connection is done trough wireless USB card, configured by ICS to 192.168.0.1 netmask 255.255.255.0.
On laptop, my wireless card is configured to acquire address from DHCP server which is running on my desktop the moment I shared the connection.
I did this - set the address of internet connection to my previous, now non-valid static address, so that nothing can be acquired trough this interface.
This is my log - as you see, this fires, and at first, I got an automatically assigned address. After, I got proper DHCP. I did, as you said set the UDP 67-68 rule as first in network monitor.
Now up to restart both machines and test if this sticks…
Here is the log…

Date/Time :2007-04-29 22:07:10
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 87.116.178.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 87.116.178.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 0

Date/Time :2007-04-29 22:06:35
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 87.116.176.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 87.116.176.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 0

Date/Time :2007-04-29 22:05:40
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.56.237, Port = nbdgram(138))
Protocol: UDP Incoming
Source: 169.254.56.237:nbdgram(138)
Destination: 169.254.255.255:nbdgram(138)
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:05:35
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.56.237, Port = nbdgram(138))
Protocol: UDP Incoming
Source: 169.254.56.237:nbdgram(138)
Destination: 169.254.255.255:nbdgram(138)
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:05:35
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.56.237, Port = nbname(137))
Protocol: UDP Incoming
Source: 169.254.56.237:nbname(137)
Destination: 169.254.255.255:nbname(137)
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:05:30
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 255.255.255.255, Port = dhcp(68))
Protocol: UDP Outgoing
Source: 192.168.0.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 0

Date/Time :2007-04-29 22:05:30
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.56.237, Port = nbname(137))
Protocol: UDP Incoming
Source: 169.254.56.237:nbname(137)
Destination: 169.254.255.255:nbname(137)
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:05:25
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.56.237, Port = nbname(137))
Protocol: UDP Incoming
Source: 169.254.56.237:nbname(137)
Destination: 169.254.255.255:nbname(137)
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:05:00
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 87.116.178.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 87.116.178.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 0

(:SAD)

After a restart of both computers - same problem again.

But this time I got something interesting in the log - check this out:

Date/Time :2007-04-29 22:20:53
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 192.168.0.35, Port = bootp(67))
Protocol: UDP Incoming
Source: 192.168.0.35:dhcp(68)
Destination: 192.168.0.1:bootp(67)
Reason: Network Control Rule ID = 0

Date/Time :2007-04-29 22:20:48
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 192.168.0.35, Port = bootp(67))
Protocol: UDP Incoming
Source: 192.168.0.35:dhcp(68)
Destination: 192.168.0.1:bootp(67)
Reason: Network Control Rule ID = 0

Date/Time :2007-04-29 22:20:23
Severity :Medium
Reporter :Network Monitor
Description:Outbound Policy Violation (Access Denied, ICMP = PORT UNREACHABLE)
Protocol:ICMP Outgoing
Source: 87.116.177.93
Destination: 70.110.177.178
Message: PORT UNREACHABLE
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:20:18
Severity :Medium
Reporter :Network Monitor
Description:Outbound Policy Violation (Access Denied, ICMP = PORT UNREACHABLE)
Protocol:ICMP Outgoing
Source: 87.116.177.93
Destination: 72.25.162.72
Message: PORT UNREACHABLE
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:19:58
Severity :Medium
Reporter :Network Monitor
Description: Outbound Policy Violation (Access Denied, Protocol = IGMP)
Protocol:IGMP Outgoing
Source: 192.168.0.1
Destination: 224.0.0.22
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:19:58
Severity :Medium
Reporter :Network Monitor
Description: Outbound Policy Violation (Access Denied, Protocol = IGMP)
Protocol:IGMP Outgoing
Source: 87.116.177.93
Destination: 224.0.0.22
Reason: Network Control Rule ID = 11

Date/Time :2007-04-29 22:19:53
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 255.255.255.255, Port = bootp(67))
Protocol: UDP Outgoing
Source: 192.168.0.1:dhcp(68)
Destination: 255.255.255.255:bootp(67)
Reason: Network Control Rule ID = 0

This machine previously had 192.168.0.35 and is now trying to renew the address… And same rule which allows also denies access…

I was wondering why you don’t just assign each computer a fixed IP address and be done with it. You can leave the DHCP settings as they are. This should take care of the DHCP issue as you will always have the same Lan IP.
I use this approach with my 5 node system and attached Lan Printer.

Lee

Yes, this is an option - but laptop does not always have same TCP/IP settings because I’m connecting it
to other wireless networks. So, it is a bit hassle to configure it all the time. I can do fine in windows by assigning alternate configuration, but when I boot Linux, network manager can be ■■■■■■■ this. So DHCP is the best option there is for me. I did make a progress with above rule - but seems that I cant always get an address. It’s like Comodo is sometimes blocking, and sometimes not. Check out the logs two posts above - same rule that allows 0.0.0.0:68 to 255.255.255.255:67 denies 192.168.0.35:68 to 192.168.0.1:67.
Beside, this should be working, should it not? (:KWL)