I finally threw in the towel on DHCP. It started acting up again so I decided to go the route of assigning my LAN a static IP address.
Boy, what an improvement! Both the firewal and my Symantec Endpoint AV start-up immediately at boot time. No more 2 to 3 minute lag for the AV and firewall to start. And that is if I am lucky and DHCP assigns a non-APIPA address.
I also like the fact that my firewall log shows the actual destination IP address versus my router gateway IP on outbound port 53 svchost.exe line items.
I am trying to shake down a couple of issues though. The main issue is why are certain logged events are not appearing in the firewall log. One event is the std. outbound port 1900 dest. 239.255… mesaage. I watched it execute through active connections but no record of it appears in the firewall log? Also none of my logged outbound autoupdater appications are being looged in the firewall event log but I did verify that that the update completed sucessfully.
Yes, I didn’t change any of my logging rules. I modified a while back the std. web browser rule to log all HTTP and DNS. I also log everything from svchost and system rules.
What appears to be missing from the logs is the std. port 1900 outbound 239.255… UDP broadcast plus the normal TCP port 80,443 stuff to MS at boot time and time sync to the MS servers. I know these have executed because I have seen them appear in the active network connections screen. One common factor is these all are svchost.exe entries.
Also some of the auto update traffic does appear in the log. I did see an entry for Adobe Reader last night in the log.
I did not add my ISP DNS servers to my trusted network. I will try that and see if that makes a difference.
What I wonder is when using fixed IP address, does these above missing svchost log entries show a dest. address of my ISP server versus their actual IP address?>
I have stateful inspection turned on for my WAN on my Netopia 3347 router. I was looking at my documentation last night and it states that in default mode, stateful inspection will block any unsolicted inbound traffic to the WAN.
Now it also states that stateful inspection is only used if NAT if off. I also have NAT turned on at the router.
I can’t find any web ref. to how DHCP interacts with NAT and stateful inspection at boot time.
Wonder if I have to open UDP port 67 there to allow inbound DHCP traffic from my ISP server?
I just did a MalwareBytes update. There is a firewall rule for this that Comodo previously created. An allow rule for the Malwarebytes update program. However what I saw in the log was a connection via svchost udp port 53 to the update site IP address. This right?
If you haven’t disabled the DNS Client service, then svchost will perform all DNS queries, these are cached and may be viewed at a command prompt using ipconfig /displaydns.
Thanks, Toggie. Great network overview article at that link. You should post it on the firewall faqs section. It did not address my question of router stateful inspection configuration but that was an academic question anyway since I am not using DHCP anymore.
I think I finally straightened out my Comodo configuration - I hope. Using the quidelines in “Configuring Comodo for Maximum Security”, I just have one global outbound rule plus the two ICMP rules and the final block rule. For application rules, I deleted all rules for svchost and system leaving just my individual programs rules in place. I also only have the one network defined for my static address assigned network card.
The result is I am again seeing log activity for my program update applications. Also I only now see svchost activity when I connect via iexplorer which is more comforting than observing log entries for it when I was not logged on to iexplorer.
I asked this question a while back in another post but never got a response. Where is correct position in the application rules for the default Comodo oubound rule. At the bottom following all user program rules, etc.?
I revisited assigning DHCP when I realized that it was needed to support a DNS server on my Netopia router.
I recommend the setup previous posted by Saul for this forum thread. His rules and network setup basically include all networks within the 192.168.0.0 - 192.168.255.255 plus the APIPA range. By definition this would include the router subnet. What I have found out that for DHCP to work correctly on a XP SP3 box, the firewall has to allow DHCP ports 67 and 68 through the router gateway address. In my Netopia case, this is 192.168.1.254. Westell’s also use that gateway address. I also observed that DHCP can be activated from a return from standby in XP, etc.
Note: You will also need the ‘UDP in/out source any ports 67 - 68 destination 255.255.255.255 ports 67-68’ broadcast rule as your first global and svchost.exe rule.
Since I have reconfigured my Comodo network and rules per Saul’s, I have had zip DHCP lease problems.
Since you are including full access to your router, I would also recommend configuring it for NAT, statefull inspection, and firewall stealth mode. If your modem does not have a built in firewall, then it might be safer to configure specific Comodo global and application DHCP rules for the router gateway address, ports 67 and 68
Here is a great article from MS that explains DHCP in detail. It does not state it applies to XP but it does: Microsoft Support.
I started having DHCP problems again so in frustration, I reinstalled my chipset ethernet drivers. I also changed my router to lease range to one IP address, 192.168.1.1. Both these appear to have done the trick - so far that is. What I did notice that when I did an ipconfig /release and /renew to reset my IP address after I reinstalled the network driver, I did see a firewall log entry for APIPA 169.x.x.x. which I never saw before in the log.
I have also seen firewall log entries for DHCP not only to broadcast 255.255.255.255 but also for my router gateway address. So unless you include your router gateway address in your trusted network, you will have to create a global and svchost.exe application rules. allow in/out udp ports [67 - 68].
hi DonZ .i’d read your posts and I understood nothing;let me explain:at first your posts looks as somebody cry for help,but latter your post looks as you are a Comodo expert,but you are not;time ago i posted somrthing,you told me to do something,thing wich was clearly wrong.don’t be sorry with me,but i advise you to be more careful.have a good time.
I remember having problems with my router when I first started using it. It did not work correctly with the default MAC address of 192.168.1.1-- After reading some help files and troubleshooting posts, I changed it to 192.168.2.1 and it has worked correctly ever since.
So far DHCP is initializing OK with IP 192.168.1.1.
I did have to change the DHCP rules to “out UDP source any port 68 dest. 255.255.255.255 port 67” and create a separate inbound rule "in UDP source any port 68 dest. 255.255.255.255 port 67. " When I created that inbound rule, I saw the DHCP Offer entry in my Comodo log appear with the source IP showing 192.168.1.1.
I also kept the in/out rule to my router gateway IP rule but haven’t seen any log activity for that lately.
Looks like Comodo has had issues with DHCP for some time. What I gleaned from the above link posting is that you have to allow DHCP access to router plus to the 255.255.255.255 broadcast address. Also in past versions of Comodo, some of the miscellaneous attack detection settings have been shown to cause problems with DHCP on some routers. All I am glad is I have finally got DHCP working for my PC since without it, access to my router by ISP was not working correctly. My router system logs now are uncluttered and free of error messages.
I spent the last few days researching the Comodo theads on this forum on the subject of routers. There appear to be be two camps. The first says access to the router should never be allowed or allowed only under very controlled circumstances. The second camp states that access to the router should be allowed and also defined in your trusted Comodo network.
I did some further experimenting and based on those results and prior ones, I say if you use DHCP, you have to allow access to your router. Now a couple important points. The first is you have to be able to trust your router. Minimally it must support NAT and it has to set on in the router. If the router has a statefull inspection option, that should be turned on. Lastly, if it has a firewall set it on also and preferably to stealth mode. If all three router options are on, nothing bad inbound will get past the router. If you cannot trust your router since none of these features are present, then your better off not using DHCP and instead, assign a static IP address to you PC network card.
As far as Comodo and DHCP goes, I set my trusted network to 192.168.1.0 - 192-168.1.255. This includes all the DHCP IP addresses the router can assign, 1 - 253. It also includes the gateway address of the router, 254, and finally the broadcast address of the router , 255. I then eliminated all the special global and application rules I previously set up for DHCP since thet were no longer needed.
One puzzeling issue that remains is every time I connect to the Net via IE, the first thing that appears in Comodo log is a DHCP entry with a source IP of 192.168.1.1 port 68 dest 255.255.255.255 port 67. I can’t tell if this is inbound or outbound since Comodo logs do not show direction. This type of DHCP activity is usually a DHCP offer or acknowledgement which would indicate it’s inbound activity.
I never made any rules and everything works fine. I just let it set up my network at installation and that was it. I never had to change any router settings or make any kind of rules for traffiic from or to it. The only thing that happens with me is that when I awake the machine from standby, sometimes it takes up to 60 seconds before I can connect to any web site or to my email. That is a minor annoyance but something that never happened when I was still using Norton Internet Security 2009.
One puzzeling issue that remains is every time I connect to the Net via IE, the first thing that appears in Comodo log is a DHCP entry with a source IP of 192.168.1.1 port 68 dest 255.255.255.255 port 67. I can't tell if this is inbound or outbound since Comodo logs do not show direction. This type of DHCP activity is usually a DHCP offer or acknowledgement which would indicate it's inbound activity.
Source = Where it’s coming from
Destination = Where it’s going to
DHCP clients originate an initial DHCP request from 0.0.0.0 port 68 to 255.255.255.255 port 67.
DHCP servers respond by sending and offer from (what ever it’s IP address is9) port 67 to 255.255.255.255 port 68.
A renewal request would be:
(What ever the IP address of the client is) port 68 to (what ever the address of the DHCP server is) port 67.
There are situations where this behaviour would deviate, such as when the original DHCP server cannot be found or when DHCP lease of the client expires.
Dch48 - If I don’t create special DHCP rules, the PC assigns a APIPA address in the 169.254.x.x range. After a period of time a private 192.268.x.x address is assigned to my network card. As you stated, this causes a delay and in my case it’s more than 60 secs.; more like 3 - 4 mins. The main problem is when this occurs, it screws up my DHCP server on the Netopia router for some reason. The DHCP server also controls assignment of the DNS server on the router.
Quill - The server port on my Netopia router is port 67. All incoming from DHCP has always been from port 68 to port 67 on my PC. I have previous verified this when I was running other firewalls including XP’s. I assume the router is sender from it’s client port and receiving to it’s server port. Below is an excerpt from my router log:
8/10/09 06:23:18 PM L3 DHCP: Initializing Service
8/10/09 06:23:18 PM L3 DHCP: Setup Server On UDP Port 67
8/10/09 06:23:18 PM L3 DHCP: Setup Client On UDP Port 68
8/10/09 06:23:18 PM L3 DNS: initializing service
8/10/09 06:23:18 PM L4 DNS: nameserver address is 0.0.0.0
8/10/09 06:23:18 PM L3 SNMP: initializing service over UDP
8/10/09 06:23:18 PM L3 DIA: Diagnostics service initializing
8/10/09 06:23:18 PM L3 FW: initializing service
8/10/09 06:23:18 PM L3 SSL: Initializing Service
8/10/09 06:23:18 PM L3 SSL: Installed Verisign, Equifax & Thawte Root CA certificates
8/10/09 06:23:18 PM L3 SSL: Initialization Success
Your router is both a DHCP client and a DHCP server. Your LAN clients get their addresses using port 68 as the source and port 67 as the destination. in just the same way, your router has to obtain an external IP address for communication on The WAN.
When I get home from work today, I will post a section from my old WIN XP SP3 firewall log that clearly shows inbound port 68 being blocked from 192.168.x.x to port 67 dest. 255.255.255.255. These trans. can only be DHCP offer, renewal, or ack…
I have yet to see anything in my Comodo firewall log for inbound activity other than ICMP or the DHCP activity from port 68 to port 67 dest. 255.255.255.255 for which I coded specific allow rules.
As far as I am concerned DHCP outbound from a client is from port 68 (bootpc) to DHCP server (router or stand alone box) port 67 (bootps). The source address is either 0.0.0.0 or 192.168.x.x DHCP assigned IP address and the dest. address is 255.255.255.255 broadcast address or the router gateway/DHCP server IP address.
DHCP inbound is from a router gateway/DHCP Server port 68 (bootpc) to client port 67 (bootps). The source address is either 0.0.0.0 or 192.168.x.x DHCP assigned IP address and the dest. address is 255.255.255.255 broadcast address or the router gateway/DHCP server IP address.
I have observer the router address being used in place of the broadcast address when my PC resumes from stand-by and TCP/IP wakes up and reinitializes
As noted above, DHCP does not conform to stateful addressing concepts.