[PATCH] Fixed transparent proxy destination lookup on FreeBSD
FreeBSD has two mutually exclusive firewalls: ipfw(8) and pf(8). Currenlty only pf(8) is supported for transparent proxy lookups of destination addresses.
This patch adds support for ipfw(8). It first checks if /dev/pf exists. If it does, it assumes pf(8) is in use. Otherwise it assumes ipfw(8) is used.
ipfw(8) is actually native on FreeBSD and much more popular than pf(8).
Patch is against tor-0.2.3.25_1
Trac:
Username: yurivict
Activity
changed milestone to %Tor: 0.2.7.x-final
Trac:
Username: yurivict
Marking for inclusion in 0.2.5; 0.2.3 and 0.2.4 are currently in bugfixes-only mode.
Can we do any checks to verify that ipfw is actually in use? Otherwise, getsockname() will succeed, but will give a (presumably local) address.
The code could be simplified by the use of tor_addr_from_sockaddr().
In get_pf_socket(), do we really want to keep trying to open /dev/pf every time we get an incoming socket? That seems pretty wasteful. Maybe we should remember that /dev/pf wasn't there.
Trac:
Status: new to needs_review
Milestone: N/A to Tor: 0.2.5.x-final-
I agree with your suggestions about tor_addr_from_sockaddr() and keeping the flag "/dev/pf exists"
On FreeBSD ipfw is the default, and to the minimal degree, is always used for the default allow-all rule. It can't be turned off completely, and also no additional rules can be added when pf is used. pf is a special-case, replacement firewall functionality. So opening /dev/pf is probably the best way to check what is the current firewall type in use.
You are right, this leaves the possibility for somebody to just connect to that address without firewall forwarding and then getsockaddr would produce the (meaningless) local address. This would be the error condition. Tor should not be trying to recursively connect to its own TransPort.
Another possibility is to allow the user to set the firewall type in config file, for example like this: TransFirewallType ipfw But this may be an overkill for this.
Trac:
Username: yurivict1 -
Well, we already need a special option for selecting TPROXY on linux (#10582 (moved)), so making a general purpose one wouldn't be too bad. I'm changing the TPROXY configuration option to be a bit more general so that we don't need one option per firewall type.
-
I've taken the option approach in branch "10267_ipfw" in my public repository at: https://gitweb.torproject.org/nickm/tor.git/shortlog/refs/heads/10267_ipfw
The relevant commits are https://gitweb.torproject.org/nickm/tor.git/commit/a7f0e0c4311a5560e30acd8abeeb0130bde282f7 and https://gitweb.torproject.org/nickm/tor.git/commit/3d5760cd50179f2652ca7e5c92c23ba711a809a1
How do they look?
It looks good. The only thing is that I think ipfw should be made default, and pf should be turned on by the option on FreeBSD.
My reasoning is that ipfw is the native firewall implementation in FreeBSD, and pf is ported from OpenBSD.
See here, in FreeBSD handbook: https://www.freebsd.org/doc/handbook/firewalls-pf.html
-
This will conflict with #10896 (moved) if we merge both; I'll work on a combined branch.
Changing to ipfw by default would be problematic because it would break all existing pf configurations. What we could do is have Tor 0.2.5 or 0.2.6 warn the users that the default will change in a later version, and then later change to ipfw by default.
-
See branch 10267_plus_10896_rebased in my public repository (https://gitweb.torproject.org/nickm/tor.git) for both branches, plus some small tweaks. I can confirm that the code looks okay to me so far and it doesn't break compilation on OSX or Linux; can somebody else confirm that ipfw still works with this branch, and that it doesn't break regular pf users?
yurivict, can you confirm that I didn't mangle your code badly or put anything inaccurate in the changes file?
See comment on #10267 (moved); recommend merging the nickm/10267_plus_10896_rebased branch for 0.2.5.4.
-
The branch for this ticket got merged as 973661394abc393e3dfd5b82de86659ecadc72a4. The commits merged as part of it were:
- Only expose clean_backtrace() if we'll implement it (211b8cc)
- ipfw TransPort support on FreeBSD (10267) (3e4680f)
- tor_addr_from_sockaddr() is applicable in ipfw code, so use it. (08ef8c0)
- Educate tor on OpenBSD's use of divert-to rules with the pf firewall. (f680d0f)
- Whitespace, doc fixes (db8259c)
- Fix OSX compilation. (c00c45f)
- Call pf-divert openbsd-specific, not no-linux (89e520e)
- Changes file for 10896 (f9719b0)
- Merge branch '10267_plus_10896_rebased_twice' (9736613)
My original patch for this ticket was lost, and this ticket was erroneously closed. tor git head still doesn't have it.
On FreeBSD /dev/pf is the second firewall, the native firewall is ipfw, and it should be supported. Missing /dev/pf is not an error.
This particular section fails on FreeBSD in src/or/connection_edge.c:
#ifdef OPENBSD /* only works on OpenBSD */ pf = tor_open_cloexec("/dev/pf", O_RDONLY, 0); #else /* works on NetBSD and FreeBSD */ pf = tor_open_cloexec("/dev/pf", O_RDWR, 0); #endif if (pf < 0) { log_warn(LD_NET, "open(\"/dev/pf\") failed: %s", strerror(errno)); return -1; }Trac:
Type: enhancement to defect
Status: closed to reopened
Resolution: implemented to N/A-
An updated patch was merged; see above for discussion why.
Does "TransProxyType ipfw" not work for you? That should cause ipfw, rather than pf, to get used.
Trac:
Keywords: andrea-review-0254, 025-triaged deleted, freebsd 026-backport added
Priority: major to normal
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.7.x-final mentioned in issue #10582 (moved)
mentioned in issue #10896 (moved)
moved to tpo/core/tor#10267 (closed)