AuthPF Configuration

[jggimi]

Originally Posted by EverydayDiesel

I am running the SSH daemon and the HTTPD daemon on the same box (its a box that just does wireless connections)

Let's look at the highlighted rule more closely.

pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT

The directive in. This is from the point of view of the platform running PF. So, this will pass packets coming inbound towards the PF platform.

The directive on. This rule applies only to inbound packets on the PF platform's athn0 interface, the innermost network (though PF doesn't know or care about that).

The directive from. This rule applies to inbound packets on the athn0 interface from any possible address.

The problem directive to. This rule applies to inbound packets on the athn0 from any address yet destined for the IP address of the authorized client, $user_ip. You are unlikely to match any traffic with this directive, for two reasons: a) The destination is your client, but the traffic is inbound, not outbound, and b) the defined ports are destination port numbers, used by servers to "listen" for requests -- your client isn't listening for service requests on these ports.

When you write a rule with port numbers, the rule uses this formal syntax, per the pf.conf(5) man page:

from <source> port <source> os <source> to <dest> port <dest>

If you leave one of these undefined, the rule will interpret this as any. And we usually leave our source ports undefined (any), because they are usually high numbered and random, for most of the common UDP and TCP services.

is this still what i want?

pass in proto tcp from $user_ip to any port $TCP_PORT

I believe so, because you want your client to use its random, high numbered source port with any server listining on destination ports 22 and 80. If you want to restrict the client to use only your ssh and webserver on the one platform, change the "any" to the address of the server that provides the services.

Can you tell me why this

pass log from any to any

is not the same as

pass out log on xl0 from any to any
pass in log on xl0 from any to any

pass in log on authn0 from any to any
pass out log on authn0 from any to any

You mean beyond readability? Your second rule fragment is focused on two interfaces (one is misspelled) and your system has one more NIC that will have IP traffic -- the pseudo-NIC lo0, for loopback traffic, using the address 127.0.0.1 on the large CIDR netblock 127/8. The first single-line rule will pass this traffic, the second ruleset doesn't consider it, and it will depend on other pass or block rules (or set skip) how that traffic will be treated.

All of the "from any to any" directives can be left out, this is the default for pass, block, and match rules. You can leave the in and out directives off also, and reduce your rule count.