1. The "auth_web" server is where requests from an unauthenticated user to
any IP address's destination port 80 are routed. That local server can place a static page telling the user to authenticate, etc. Once a user is authenticated (this means having an active SSH console session to an authpf login shell on the server running PF), this traffic is no longer intercepted and can go where the user intended.
2. The
authpf_users table is described in both the
AuthPF chapter of the PF User's Guide and in the
authpf(8) man page. I'll quote from the Guide.
Quote:
|
In addition to the $user_ip macro, authpf will make use of the authpf_users table (if it exists) for storing the IP addresses of all authenticated users. Be sure to define the table before using it...
|
3. This is the author's known external (Internet) static address. See the comments above the last two rules in that HOWTO, where the macro is used. We try not to put our actual Internet address in public forums when we share our rulesets. Weaknesses might be discovered and exploited. The Internet is a dangerous place.
4. Anchor options are discussed in the
Anchor chapter of the PF User's Guide.
I'd mentioned this chapter to you two days ago, in your thread on scheduling connections.
----
Many years ago, I ran something similar in the pre-WPA days, when WEP was the only "hardware" encryption available and was known to be insecure.
I later replaced the authpf solution with an IPSec solution, as it was easier for the client -- no SSH session to maintain, and its encryption wasn't proven to be broken like WEP.
The IPSec solution was later replaced with WPA2, as clients could include systems that did not have IPSec capabilities.