Verification and Simplification of App. and Net. Rules

Hello to everyone on the Forums here.

I just converted from the Free ZoneAlarm version tonight after reading some rather disparaging remarks about ZA’s performance. (You’ve got to love cripple-ware, huh?)

At any rate, after browsing around these Forums for help in regards to optimizing my Azureus for download speeds, I created some rules and rebooted, only to discover that I had completely shut off my browser’s access to the Internet (but Azureus still maintained connectivity with no NAT problems). After creating App. Rules for svchost.exe and FireFox and rebooting, I still had no access until I turned off CPF. After further browsing, I created a Trusted Zone and so forth, but now my speeds are severely crippled.

My question is as to whether someone is willing to review the slew of rules I have here and refine (or eliminate) some of them to streamline my Internet speeds.

I guess the description of the networking environ is in order. I am on a wireless network (DHCP is enabled on the router, but I have assigned myself a static IP of; the router is at My Azureus is set up to listen for TCP on 55000 and UDP on 57500 and UPnP is disabled.

Links to screenshots follow:

Application Rules –

Networking Monitor Rules –

Thanks in advance for the assistance and, for the record, I am loving CPF so far.

Welcome to the forums, amalgam (:WAV) (what are you an amalgam of?.. :slight_smile: )

Not sure exactly what you’re trying to accomplish with all your network rules, although I gather you’re aiming for security. The result, however, looks a little haphazard.

If you go to Security/Tasks/Create a Zone; you can define that for your router/DHCP server. DNS server may also be handy. Then use that Zone with Security/Tasks/Define a trusted new network. Each time you do this (provided the Zones are different) it will create two rules in Network Monitor. The first will Allow IP Out from Any to Zone. The second will Allow IP In from Zone to Any. This will encompass the GRE, TCP, UDP, etc that you currently have in your rules (basically, rules ID 0, 3, 4, 5).

Your current rule ID 6 will completely invalidate rule ID 7 as far as TCP goes, thus eliminating port requirements. This is because the traffic filters thru the rules from the top down.

You might want to check out this thread. It’s a locked compilation of tutorials - locked meaning no replies there, so it’s easier reading. You’ll find explanations of CFP’s layered rules, network rules, default rules, application/gaming/p2p rules, etc. Each has an embedded link to the original post.,6167.0.html. It may be helpful to you.

More helpful to us will be your logs when the undesired activity occurs (ie, messed up internet connectivity). If you will do the following:

Go to Activity/Logs. Right-click and select “Clear all logs.”
Then browse, carry on normal activity. When you experience the issue(s) you mentioned, go back to Activity/Logs, rightclick and select “Export to HTML.”
Save the file. Reopen it, Highlight the entries surrounding the appropriate timeframe, Copy the highlighted field, and Paste it into your next post here. You may mask out your personal/external IP address with “x” for privacy.

That will show us what’s going on at that point in time. For diagnostic purposes, the less extraneous info in the logs the better, so if you can limit your activity to only what will produce the error, that’s best (in other words, don’t be running multiple torrents, downloading from cnet, doing some rss feeds, running an online AV scan, etc all at once…) :). If the problem happens when browsing, try just to be browsing.


Amalgam is a name I’ve used for years now in online gaming and I’m known by it in some places; it’s also the old name I used back when I offered graphic design services professionally. Those days are gone but I’ve kept the moniker. It was intended to be something like “an amalgam of styles” because my partners and I all had very different design and coding styles.

Heh, I saw the compilation of tutorials and I read through them and applied what I needed to them: I think that’s what got me into trouble in the first place.

The router is a public-access one so I had a bit of trouble figuring out what ports they had not forwarded. This is also part of the reason I want to completely block network access to my machine and why I have modified the “FROM NETWORK IP TO ANY FROM ANY PORT” rule to Block all.

Aside from that, I’m just looking for the simplest set of rules that will do what I want. And once I get this figured out, I’m going to be forcing my father to adopt this firewall as well (he’s currently running ZA Free), as well as my brother.

The connectivity seems better today since a restart, so I don’t know if I can reproduce the slowdown, but I’ve cleared the logs anyway.

Thanks for the assistance.

Woppsies! GUess I won’t refer you back there again! :wink:

You may find it easier to simply open up UDP Out DestPort 67, UDP In DestPort 68 (to/from the DCHP server IP). Make a matching rule in AppMon for svchost.exe. That way your DHCP will go thru. If you set any Inbound rules in NetMon, make sure you have a matching application rule in AppMon.

With CFP, having an In NM rule will only access if there is an actively listening application on that port. That’s why when you shut your p2p app, you’ll get a lot of log entries all of a sudden; it’s no longer accessible, and the torrent doesn’t know it yet. So the forwarded router really isn’t a threat, IMO. As long as you don’t have an In rule in NM, for that port, and an application running that is allowed to Listen on that port, you should be fine; it will be blocked (provided you don’t get rid of the bottom Block & Log All rule).

Your basic flow would be to create very specific rules to allow ONLY what you want (use separate In and Out rules; not combined - so there’s no confusion about IP or Port, in regards to direction of traffic). Then Block the rest. Remember than In only refers to an unsolicited Inbound request; not a response to an Outbound request.

Hope that helps.


Thanks for the response! You’re helping out enormously.

OK, so my new rules are as follows:

Network Monitor Rules

Allow IP In FROM (the router) TO Any WHERE IP Protocol=Any

Allow UDP Out FROM Any TO WHERE Source Port=Any Dest Port=Any (Catch-all UDP Rule)

Allow UDP In FROM TO Any WHERE Source Port=Any Dest Port=68,57500 (Not sure whether Source or Dest should be set to 68: does the router authenticate all network members on 68 or does the 68 refer to my 68? The 57500 is my custom Azu UDP Listening Port.)

Allow TCP In FROM Any TO Any WHERE Source Port=Any Dest Port=55000 (Custom Azu TCP Listening Port)

Allow TCP Out FROM Any TO WHERE Source Port=Any Dest Port=Any (Just to ensure connectivity to the Internet.)

Allow TCP In FROM TO Any WHERE Source and Dest Ports=Any (This will probably get refined to be restricted to 21, 80, 432, 8080, and a handful of others for the Dest. Ports to eliminate unwanted trafiic and/or security threats.)

Allow IP Out FROM Any TO WHERE IP Protocol=Any (It seems to not work without this rule. I presume this is what allows me to obtain an IP address…but the aforementioned UDP rules should handle this. Something seems off here.)

Block IP In FROM Wireless Network Zone TO Any WHERE IP Protocol=Any (Blocks everyone else from accessing me, since it’s a public wireless network.)

Block IP In FROM Any TO Any WHERE IP Protocol=Any (The default block catch-all.)

Application Monitor Rules

Azureus – Allow TCP/UDP In/Out (full access)
CMD – Allow TCP/UDP In/Out (full access) “Command Prompt” for Windows XP.
Firefox – Allow TCP/UDP In/Out (full access)
svchost.exe – Allow UDP In on 68,57500///Allow TCP/UDP Out on all ports///TCP In on all ports

Thanks again for the input, Little Mac.

In summary: - Port 67 is the DHCP server's port, used to receive DHCP requests and send DHCP 'offers'. - Port 68 is the client's port, used to send DHCP requests (to the server) and receive DHCP offers (from the server)
He says it more succinctly than I can, I think. DHCP stuff makes my head spin. :) So yes, 68 In is the port.

If we number your rules top to bottom, starting with Rule ID 0, where Rule ID 6 would be the one you say it won’t work without, then I would remove Rules ID 1 & 4 (your default UDP & TCP rules, respectively), as they are redundant at that point. I agree Rule ID 1 should take care of the DNS, but your system/setup may use some other protocol in conjunction with that. You can watch Activity/Connections as it’s happening (or disable it on purpose, then Repair it, to watch the process), to see what Protocols are used. Or, set that rule to Log, and reference against that.

Here’s my big concern, though (and maybe it’s just a typo…), but rule ID 5 scares me. Why do you have a rule set to Allow In from the router to your computer? Remember, unless you’re running applications that make use of unsolicited inbound traffic, you don’t want an inbound rule. Nor do you need it. As Pepoluan explained in the other thread, TCP makes use of headers to identify response traffic, so you don’t typically need a rule like this. Are you trying to work something specific with that?


I forgot about the TCP I/O response thing. I was actually going to restrict that rule down to ports 21, 80, 443, etc. just for specific responses (FTP, HTTP, Secure Connections, HTTP Alternate, etc.) and then let everything else cascade down to the default block-all. I see your point about it being extraneous. Nice catch.

Will the Application Monitor Rules be sufficient for what I am looking to do or should they be strengthened?

Thanks again for the swift response.

If you want to really tighten things up, you will create “matching” NM and AM rules. For example, if you set your email client to AM rule to Allow TCP Out to 123.345.56.67 on Destination Port 25,110, then you want to match that rule in the NM. So you’d have a rule to Allow TCP Out to Destination IP on Destination Port.

You’d do that for each entry in the AM, and in the NM, those would be basically the only rules you have, except the Block rules. So the only traffic that would be allowed, would be that which was explicitly allowed by both NM and AM.

As compared to implicit rules, where you might simply Allow your email client TCP Out. Or even if you had some detail on the AM rule, but the NM rule was simply to Allow TCP Out to Any, then that would implicitly allow (general/loose details) rather than explicitly allow the specific details.

All that said, that’s a matter of preference. If you go to the super-detailed matching rules, you’re likely (my experience) to run into some connectivity issues at some point, as some things just don’t seem to behave as we think they should… :wink: Also, the level of detail in your AM rules MUST match the level of detail supplied by the Alert Frequency setting (Security/Advanced/Miscellaneous), or the rules will be constantly overwritten every time the application connects to a new website or upgrades any components.

Keep in mind that since the NM sets the groundwork/foundation for all traffic, you’re pretty much secure as long as you don’t create any broad invitations in your rules for accepting Inbound traffic. (such as my alarm at Rule ID 5…) I only use a smattering of detailed rules, and only a minor match, rather than a major one; it’s a blend of security and function.