[jggimi]

Originally Posted by heatherval

My other problem is when I change my $ext_if and $_int_if as you sugested...

My recommendation was to not ever confuse loopback virtual interfaces with any sort of physical network connection. You had set $ext_if to "lo0" and this confused me, and apparently, confused you too.

I never mentioned $int_if, and you have neither explained nor shown what this means.

As I tried to tell you, macros are only variables, that are used for keyword substitution. And perhaps you're confused between the terms "internal" and "external". Allow me to try to enlighten you. If this is review, please forgive me. Based on what you've posted, my perception is of a person who continues to be confused.

A computer with more than one physical network interface can be used as a router -- to route packets between one network and another. If your computer has multiple network interfaces, and they are connected to separate networks, you can enable packet forwarding and route packets from one interface to the other. When a computer does this, we term it a "router." Your Linksys router does this, routing between your ISPs network and your private network. OpenBSD systems can do this, too, if they have more than one Network Interface Card (NIC).

PF doesn't know which of your interfaces might be used for a local network, and it doesn't know which of your interfaces might lead to the Internet. All it knows is that you have interfaces. You tell it which packets are permitted to flow inward from particular interfaces, and which packets are permitted to flow outward along particular interfaces. That's it.

PF configuration files permit the use of "macros" -- its not the best name, because these are nothing more than variable substitutions for strings. e.g. your pf.conf file could have:

permit = "pass"
prevent = "block"

... and then use $permit and $prevent later in the file to mean pass and block. It's nothing more than that.

Why use PF macros? For convenience, and clarity.

Convenience: If your pf.conf had 50 rules for your rl0 interface, and then you changed computers and used another interface, would you rather make a single edit, or 50 edits?

Clarity: If you named your interfaces for the network(s) they attach to, you are less likely to make a mistake. For example, one of my OpenBSD machines is a router with two different interfaces: vr0 connects to computers on a local, internal network, and dc0 connects externally to the Internet. I use "$internal_nic" and "$external_nic" as my variable names -- macros -- for these so that when I am reading the pf.conf file I never have to remember which physical interface connects to what, and the rules make sense to me, or would make sense to other readers.

I believe you only have a single interface ... at least, I presume that from what you have posted. In this case, there is no concept of "internal" or "external" networks, since you only have the one.

...it will hang till I break it

There is a serious error; whether it is configuration problem or a software problem I can't say, because you have not provided enough information. Post this changed pf.conf, and please, post your dmesg(8). And please use code tags, as Ocicat recommended when he edited your first post.

Would fwbnuilder help me also learn at all?

I doubt it. It appears you first need to spend time learning the basics of computer networking; PF scripting requires an understanding of how your applications use a network.

Now if I get the book you refered or read the faqs am I supose to look for the current verion I am using 5.0?

The FAQ, including the PF Users Guide, will always apply to the most recent release.

Another question I have... is this
if I decide to install a package at any timne since I have my PKG_PATH and PKG_CACHE set
how can I access the files if my pf rules are set the way you have them the way I prefred

You cannot. The two line (or three line if you use $interface) pf.conf file will only permit outbound traffic in response to inbound traffic on port 7008. You would have to add additional rules to cover this use case.