Internet connection going out [Resolved]

My internet connection has been going out, just like that, out of the blue for the last two weeks. I would like to eliminate the possiblity that my firewall is causing the problem. I don’t get any firewall prompts, what happens is that my modem tries to renew my IP address which it doesn’t and then I have to either reboot or disconnect the power cord from my modem, shut down my computer, reconnect the power cord to my modem, wait for my modem to reaquire service and then turn my computer back on in order to get online. I connect to the internet with a cable modem via an ethernet connection. I have an onboard eithernet connection. I have windows xp home edition with service pack 3. If I go to the command prompt, and then use the ipconfig command, the connection-specific dns suffix and the default gateway field is blank while the autoconfiguration ip address and the subnet mask field is not blank. When my internet connection is working, the autoconfiguration ip address is changed to just ip address. Going to the event viewer, I have this:

date: 7/5/2008
time: 7:41:43 AM
type: error
user: n/a
computer: HOME-1JB298VQN8
source: dhcp
category: none
event ID: 1000

description:
your coputer has lost the lease to its IP address 76.168.59.200 on the network card with network address 001060168E43

For more information, see Help and Support Center at

According to my event viewer, my internet connection has gone out at the following times.
12:08 AM
5:34 AM
6:36 AM
7:41 AM
8:47 AM
9:57 AM
11:00 AM

The Event Log entry is telling that the DHCP address renewal is being blocked. Is there anything in your CFP log?
In v2.4, you click Activity → Logs. If you right click anywhere in the log, you’ll get a menu that will let you export the log to html, which you can post here.

Your first post mentioned a modem. What kind of connection do you have? Is this a modem, or a modem/router combination?

I called into time warner and I found out that my firewall may be causing my internet connection to go out so I have my firewall turned off right now to confirm whether or not, that is the problem. The log file is too big to post here so here the link for it.
C:\Documents and Settings\Owner\Desktop\Misc\log file for comodo firewall.html

Since that link is on your computer, I can’t get to it to see what is in the log.

So, let’s try a different approach, with a screen shot.

Bring up the CFP log (Activity → Logs), and take a “snapshot” by pressing Alt-Prntscrn. This will copy the window onto the system clipboard.

Now, open Notepad (or Wordpad, or Paint), and do a Cntl-V for a normal paste operation. You should have the image of your window. Save that image as a file. Then you can post that file here.

To post the file, there is the “Additional Options” in the Comodo forum post page. You want to Attach the file, so when you Post, that file will show up here.

One problem. I took screenshots of the log, pasted the screenshot into paint and then saved that as a file. The file size is at least 3.75 MB which is way more then what I can post here.

I have another method, I’ll use image shack to get links which I’ll post here. It’ll be one link per image.
Screenshot #1

Screenshot #2

Screenshot #3

Screenshot #4

Screenshot #5

Thank you. As you likely noticed, you have a lot of entries complaining about svchost.exe and IP address 255.255.255.255. That’s the problem.

svchost.exe is the Windows system component that renews your IP address automatically (among other things that svchost.exe does). CFP is blocking it.

To remove the block, open CFP and click Security → Application Monitor. Find the line (or lines) that have svchost.exe and permission as “blocked”. Click on each line to highlight it, then click Remove (in the upper right corner). That should get rid of the block, and all those “Application Access Denied” messages in the log.

You probably should add these rules to make sure that the DHCP address assignment gets thru in the future. Click Security → Network Monitor, and then Add

Action: Allow
Protocol: UDP
Direction: In/Out
Source IP: Any
Destination IP: Single IP: 255.255.255.255
Source Port: Any
Destination Port: a port range: Start 67 End 68

The click OK. You’ll have a new rule as the very last rule. You need to move it up to the top of the rule list, so it is first. Click the line to highlight it, and Move Up as needed.

Another new rule to put into place. Your log is showing some DHCP replies being blocked, and this new rule should keep that from happening.

Action: Allow
Protocol: UDP
Direction: In/Out
Source IP: IP Mask: IP 10.0.0.0 Mask 255.0.0.0.0
Destination IP: Any
Source Port: Any
Destination Port: a port range: Start 67 End 68

Click OK, and the move this new rule up to be your second rule.

Then clear your logs, so we can see what is happening with these new rules. Click Activity → Logs, right click in the log, and select Clear All Logs. Then exit CFP.

To test things out real quick, you can do a reboot. Then look at the CFP logs again. You should be okay. But watch things for a little while.

Your logs are showing some other traffic that needs to be looked at, but first we need to get your a good working connection.

I followed your insructions so I’ll monitor everything for a bit and see what happens.

I wanted to provide you with an update. So far, my internet connection has been good. I am getting warning in my event viewer, but those aren’t as bad as red X’s. They may have to do with the other things, I really don’t know. I’ll continue to monitor everything in the next few days.

Unless you feel that it’s too early, I’d like to go on ahead and take care of the other traffic that’s being blocked. My internet connection has not gone out so far which is good.

Good to hear that your connection is working now. And, no, it is not too soon to look at the other stuff.

Your earlier logs were showing what look like a bunch of probes, and some likely misconfigured network “neighbors”. But with all that svchost.exe blocked messages filling the log, it was hard to tell. Now that the svchost thing is cleared up, the log should be able to properly show what’s going on.

So, if you could post your CFP log,we can see what’s what. With a smaller log this time, you should be able to export it to a file. Or you can make screen snapshots as you did before. Your choice.

The other thing I’d like to see, is what your firewall rules are. It may be that rearranging the rules, or adding some additional rules, can help to keep your machine safe. There’s no means to export the rules, so you’ll have to do it as a screen snapshot. Open CFP, maximize the screen, click Security → Network Monitor, and the capture the screen image.

And, I want to confirm what I guessed at from your earlier logs. That you are connecting thru a cable modem, like this:

 Internet ------- modem -------- PC

and not like this, with a router or some other box in the middle:

 Internet ----- modem ------- router/box --------- PC

Thanks.

My log is not quite as long this time, but you’ll have to bear with me. Same setup as before and to answer your last question, the first diagram would be correct. I don’t have a router or box of any kind.
Screenshot #1

Screenshot #2

Screenshot #3

Screenshot #4

Screenshot #5

Screenshot #6

Screenshost #7

Screenshot #8

Screenshot #9

Screenshot #10

Screenshot #11

Screenshot #12

Screenshot #13

Screenshot #14

Screenshot #15

Screenshot #16

Screenshot #17

Screenshot #18

Screenshot #19

Screenshot #20

Got it. Thank you. It’s going to take me a little while to work thru the logs. I’ll have some rule change suggestions for you later that should help cleanup the logs a bit. Today’s dayjob schedule is a bit busy, so it may be tomorrow before I can get it all worked out.

By all means, take your time. I’m in no rush.

Here’s a rule for you to add, just based on the sheer volume of entries in your log. All that “inbound policy violation” on ports 1026, 1027, and 1028 is very very typical for what is often referred to as “net send” spam. This is the stuff that causes a popup message box that says something like this “Warning. Your machine is infected. Visit and download immediately”. You’re right to have that blocked. But it is filling up the log to no effect.

So, here is a blocking rule, without the logging. Click Security → Network Monitor, then Add

Action: Block (do not check the alert box, that will produce a log entry)
Protocol: UDP
Direction: In/Out
Source IP: Any
Destination IP: Any
Source port: Any
Destination Port: a port range: start 1026 end 1028

Click Ok, and you have a new rule. Use “Move Up” to move this new rule up just one position, so it comes just before that last “block&log all from any to any” rule that is giving all the log entries.

And, can you give me a screen snapshot of your Network Monitor rules?

I’m still going thru your logs as I get the time. I’ll likely have some additional rules for you to add.

I added the blocking rule. My network monitor rules are posted below.
Screenshot of network monitor rules

Having had the chance to go thru your logs in detail, I found myself pleasantly surprised. Your logs are actually quite clean, after all that port 1026-1028 stuff gets out of the way. In fact, there is traffic missing that I was expecting to see, which tells me that your ISP is filtering it. That makes your ISP one of the few really good guys on the Internet.

What your ISP seems to be doing, is blocking all Netbios traffic (ports 135-139). Windows in all of its versions, is a very chatty system, and tries to broadcast its LAN file sharing to one and all. The malware folks take advantage of that “broken by design” feature, and try to attack the Netbios ports. There’s not one entry in your entire log showing any probes. That means your ISP is blocking the ports.

Since you’re running the CFP default rules, for the most part, that means that your machine is trynig to broadcast any Netbios traffic it has outbound to the Internet. If you were on a LAN with a NAT/router box, that wouldn’t be a problem. But since you have the one machine, and are directly connected to the modem, that means the traffic is going out to the ISP routers. Then the ISP routers just drop the traffic. So you’re safe.

I’ll suggest adding these two rules, to serve as a backup to make sure that LAN networking traffic doesn’t accidently leak out to the Internet. If you ever get a NAT/router box, or a second PC, these new rules will block any sharing or contact with that box or other PC. Just be aware of that for the future.

Your existing rule 2 (Allow TCP/UDP Out Any Any) is the rule that lets your machine talk to the Internet. These two new rules have to go just ahead of your existing rule 2.

The first new rule, which will block Netbios traffic:

Action: Block (do not check the box for alerts)
Protocol: “TCP or UDP”
Direction: In/Out
Source IP: Any
Destination IP: Any
Source Port: Any
Destination Port: a set of ports: 135,137,138,139,445

The second new rule, which will block “multicast” traffic used by NAT/routers and Windows UPnP:

Action: Block (do not check the box for alerts)
Protocol: IP
Direction: In/Out
Source IP: Any
Destination IP: IP mask: IP 224.0.0.0 mask 240.0.0.0

With these two rules, you machine is much less likely to leak anything out to the Internet. Your ISP is already blocking this traffic, so these rules are just a backup.

Something that did show up in your log in a few instances, were some blocked ICMP messages. ICMP is one of those background things that traffic flowing reasonably efficiently. In particular, are the ICMP error messages. The Internet equivalent of a telephone busy signal, or an answering machine that says “sorry, nobody home and voicemail is full”. There are about a dozen or so ICMP error messages. The default rules that you have in place, are letting in two of those dozen messages. You need to add a few more.

Since all of the ICMP rules are the same, except for the ICMP details, here’s the template:

Action: Allow
Protocol: ICMP
Direction: In
Source IP: Any
Destination IP: Any
ICMP Details: <the following list, one new rule for each>

The ICMP rules you need to are are for “ICMP Net Unreachable”, “ICMP Host Unreachable”, and “ICMP Port Unreachable”.

Your existing rule 5 is the “allow ICMP In — Time Exceeded”. These three new ICMP rules go after your existing rule 5.

After all those rule changes, you can clear your CFP log. And you should be good to go at this point. Watch your logs for a day or so. You’ll still see stuff in your log. That’s just the normal variety of junk on the Internet these days. And it means that CFP is doing its job. If you see anything in the log that you’re not sure about, you can post it here.

You’re one of the few people that I meet online that actually says something nice about AOL, since that is my ISP. In the past, when I had issues, I would always hear “Get rid of AOL” Not very nice to say since it’s my choice to begin with. Here is a list of the new rules that I added. Does the order matter?
Rule #1

Rule #2

Rule #3

Rule #4

Where you give me the template, I’m confused because I don’t know where I add the ICMP details.

Looks like you need to move rule 8 and rule 9 up, so they are after rule 1.

You should wind up with a rule order that is like this (abbreviating the rules for ease of writing here)

  1. Allow TCP/UDP ----- 255.255.255.255
  2. Allow TCP/UDP Mask 10.0.0.0/255.0.0.0
  3. Block TCP/UDP — Mask 224.0.0.0/240.0.0.0 # your current rule 8
  4. Block TCP/UDP --------- Ports 135,137,… # your current rule 9
  5. Allow TCP/UDP Out Any Any Any Any

And, yes, order does matter. CFP reads the rule from the top down. The first matching rule is the one that gets applied. If your machine is sending something out, the first matching outbound rule will let the stuff out. That’s going to be, in my list of what should be, rule 4. So anything that is going out, has to come before that rule.

The ICMP detail is on the ICMP Details tab. When you select ICMP as the Protocol from the pulldown list, you’ll see the tabs change, and you’ll see an ICMP Details tab. The pulldown list for the ICMP message type has the three message types. Use one per rule.

Way back when, 10 to 15 years ago, AOL had some problems. They’ve done a lot, and gotten their act together over that time. Today, they’re one of the better ISPs out there. In this case, they’re doing the right thing with their filtering, and I commend them.

Adding all the rules, this is the order that I have.
Network monitor rules for comodo firewall