TransPort, DNSPort, and pf

Roger Dingledine arma at
Fri Dec 31 08:49:24 UTC 2010

On Fri, Dec 31, 2010 at 12:53:10AM -0600, Scott Bennett wrote:
> hellas# su _tor
> $ tor --verify-config
> Dec 30 23:33:41.799 [notice] Tor v0.2.2.17-alpha (git-dadd9608d2720368). This is experimental software. Do not rely on it for strong anonymity. (Running on FreeBSD i386)
> Dec 30 23:33:41.817 [warn] open("/dev/pf") failed: Permission denied
> Dec 30 23:33:41.818 [warn] Failed to parse/validate config: Unable to open /dev/pf for transparent proxy.
> Dec 30 23:33:41.818 [err] Reading config failed--see warnings above.
>      My first question is, why does tor want to open /dev/pf when all packets
> from the internal network are redirected to tor on the loopback interface
> anyway?

Because Tor still needs to be able to learn where the original destination
was. Looks like it asks your OS that question through /dev/pf.

See connection_ap_get_original_destination() in src/or/connection_edge.c

>  To get tor to stop complaining, I had to change the group of /dev/pf
> from wheel to _tor and change the device's permissions from 600 to 660.

Hm. I'm going you're on net or free bsd?

Quoting from get_pf_socket():
#ifdef OPENBSD
  /* only works on OpenBSD */
  pf = open("/dev/pf", O_RDONLY);
  /* works on NetBSD and FreeBSD */
  pf = open("/dev/pf", O_RDWR);

No idea why it would need read-write in particular on /dev/pf, but who
am I to answer the mysteries of BSD.

In any case, Tor expects you to start Tor as root if you want the pf
support to work, so it can open your /dev/pf correctly. That means you
should use the 'user' torrc option and Tor would drop privs once it's set
things up. (See the call to get_pf_socket() in options_act_reversible().)

>  It
> seems to me that neither should be necessary and that tor should not access
> /dev/pf.

Do you know another way to do transparent proxying on BSD? I confess
that Linux's way (a getsockopt call) does look simpler. :)


More information about the tor-relays mailing list