Rules generated from selecting Allow in alert window are too loose

I run an application (happens to be SocketWatch which is a time sync utility). An alert popup from CPF appears telling me:

Application: swatch.exe
Remove: (some NTP server host) - UDP
Port: ntp(123)

When I select “Allow this request” and click the OK button, I figured a rule would get generated based on the displayed criteria showing what protocol and port were being requested for the connection. That is, I expected a rule like:

Allow IP Out from IP Any to IP Any Where Protocol is UDP

However, even this rule has some ambiguities.

  • Why would the protocol at the source be different than the protocol for the destination? If I use UDP to connect to an NTP server, aren’t I using both UDP at the source (my host) and also at the destination host? So why wouldn’t the rule be:

Allow UDP Out from IP Any to IP Any Where Protocol is UDP

And if the same protocol is required at both end of the connect then it seem superfluous to specify the protocol at both ends so the rule would be:

Allow UDP Out From IP Any to IP Any

  • Why would I allow “from IP Any” when obviously the software firewall is only running on my host? Seems superfluous to specify the source since the source is going to be my host, so the rule would become:

Allow UDP Out From localhost to IP Any

but then the “From localhost” is also superfluous so the rule becomes:

Allow UDP Out to IP Any

The only reason that I can think of using “from IP Any”, “from IP ”, or any “from” parameter is if I operated my host as a gateway and wanted to allow a inbound connection to then connect elsewhere - but then the app rule couldn’t be defined anyway because there is no “app” involved in that gateway connection (i.e., you couldn’t define an app rule for just the traffic that you gateway host received because the app itself isn’t running on your gateway host). Is it possible to have multiple IP addresses assigned to the same host? I must be too sleepy to see why the “from” even has to be specified in the rule.

  • The destination would probably have to remain vague and require manual editing since apps that connect may go to one host but then bounce to somewhere else, like when navigating to differnet domains in a web browser, so I can see why the generic “to IP Any” gets shoved in the rule generated by selecting Allow in the alert window.

The above is for an outbound-only rule where it seem superfluous that the “from” host must be specified. For an inbound-only rule, the “to” host seems superfluous since it will obviously be your host. These fields seems to be just superfluous placeholders for when an in/out rule is defined but it seems the logic could be written to simply obviate the superfluous parameter in a one-directional rule.

The “Allow” in the alert window generates a loose app rule. Seems to avoid making the user to remember to go back into CFP to do manual editing of the rules that a “Create rule” selection should be added that would prefill in the already detected IP addresses, ports, protocols, and other data so the user could start with an overly loose rule and tighten it up (or a tight rule that they would loosen) as they got prompted regarding the connection request. I’ve seen plenty of rules in other firewalls that are generated by these alert windows and rarely do users actually go back to the generated rule to see if they want it more tight or more loose.