doc/TransparentProxy.md

-[[TOC]]
+
 
 = [[span(style=color: #FF0000, WARNING:)]] USING TOR AS A TRANSPARENT PROXY IS [[span(style=color: #FF0000, HIGHLY DISCOURAGED)]]. DO NOT ATTEMPT IT UNLESS YOU KNOW WHAT YOU ARE DOING!
  * Copyright (C) 2006-2007, 2010, 2014 (tup, maxigas, et al.)
  * Distributed under the X11 license
- * See [wiki:doc/LegalStuff] for a full text
+ * See [doc/LegalStuff](doc/LegalStuff) for a full text
 
-== Transparently Routing Traffic Through Tor ==
+## Transparently Routing Traffic Through Tor
 
 Tor has support for transparent proxy connections in addition to SOCKS connections. With traditional proxy methods like SOCKS, setting up the proxy server itself isn't enough; proxy-supporting applications must be chosen, and each application on each machine using the proxy must be specially configured by the user or network administrator to connect through the proxy. Sometimes this isn't possible because an application doesn't support SOCKS, or the administrator doesn't want users to know their traffic is being sent through a proxy. These problems can be avoided by using your operating system's packet filtering facility to redirect outbound connections into a transparent proxy, so named because its presence is intended to be invisible to clients.
 
 This document details two common uses for Tor's transparent functionality. The first is routing all traffic on a standalone machine through Tor. Once this is set up, every network application will make its TCP connections through Tor; no application will be able to reveal your IP address by connecting directly. The second is creating an anonymizing middlebox that intercepts traffic from other machines and redirects it through Tor.
 
-== Brief Notes ==
+## Brief Notes
 
 Currently, transparent proxy connections are only supported for netfilter in Linux and pf in BSD.
 
-Please read [https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxyLeaks Transparent Proxy Leaks] (mostly Microsoft Windows related) and/or consider an [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy Isolating Proxy] as alternative.
+Please read [Transparent Proxy Leaks](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxyLeaks) (mostly Microsoft Windows related) and/or consider an [Isolating Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy) as alternative.
 
-See [https://www.whonix.org Whonix] for a complete, ready-made VM based solution (alternatively using multiple physical computers) built around the [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy Isolating Proxy] and Transparent Proxy [https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#AnonymizingMiddlebox Anonymizing Middlebox] design.
+See [Whonix](https://www.whonix.org) for a complete, ready-made VM based solution (alternatively using multiple physical computers) built around the [Isolating Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy) and Transparent Proxy [Anonymizing Middlebox](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#AnonymizingMiddlebox) design.
 
-Since a transparent proxy operates without application support, we have to accept ordinary DNS requests and somehow resolve them through Tor in order to avoid anonymity compromising [wiki:doc/TorFAQ#SOCKSAndDNS DNS leaks]. Tor versions starting with 0.2.0.1-alpha have a built-in DNSPort designed to operate as a limited DNS server.  We will cover this later in the document.
+Since a transparent proxy operates without application support, we have to accept ordinary DNS requests and somehow resolve them through Tor in order to avoid anonymity compromising [DNS leaks](./doc/TorFAQ#SOCKSAndDNS). Tor versions starting with 0.2.0.1-alpha have a built-in DNSPort designed to operate as a limited DNS server.  We will cover this later in the document.
 
-Here is an outdated discussion, though it is good to remember: [https://lists.torproject.org/pipermail/tor-talk/2013-April/027709.html tor-talk Tor transparent proxy leaks?].
+Here is an outdated discussion, though it is good to remember: [tor-talk Tor transparent proxy leaks?](https://lists.torproject.org/pipermail/tor-talk/2013-April/027709.html).
 
-= WARNING =
+# WARNING
 
 '''Possible leak! Released March 28th, 2014 - Please incorporate the following iptables rules as they have not been incorporated into this article!
 
-* '''[https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html Linux kernel transproxy packet leak (w/ repro case + workaround) #1]'''
-* '''[https://lists.torproject.org/pipermail/tor-talk/2014-March/032507.html Linux kernel transproxy packet leak (w/ repro case + workaround) #2]'''
-* '''[https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html Arguments against the transproxy approach.]'''
-* '''[https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html Arguments against the transproxy approach.]'''
-* '''[https://github.com/epidemics-scepticism/writing/blob/master/misconception.md#transparent-proxy-and-tor-router Arguments against the transproxy approach.]'''
+* **[Linux kernel transproxy packet leak (w/ repro case + workaround) #1](https://lists.torproject.org/pipermail/tor-talk/2014-March/032503.html)**
+* **[Linux kernel transproxy packet leak (w/ repro case + workaround) #2](https://lists.torproject.org/pipermail/tor-talk/2014-March/032507.html)**
+* **[Arguments against the transproxy approach.](https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html)**
+* **[Arguments against the transproxy approach.](https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html)**
+* **[Arguments against the transproxy approach.](https://github.com/epidemics-scepticism/writing/blob/master/misconception.md#transparent-proxy-and-tor-router)**
 * This article does not address IPv6 firewall rules settings properly (ip6tables).
 
-== Reserved blocks ==
+## Reserved blocks
 These addresses shouldn't be routed through Tor:
  * 0.0.0.0/8
  * 10.0.0.0/8
@@ -53,65 +53,65 @@ These addresses shouldn't be routed through Tor:
  * 240.0.0.0/4
  * 255.255.255.255/32
 
-== Linux (netfilter) ==
+## Linux (netfilter)
 
-'''Required software:'''
+**Required software:**
  * iptables 1.3.5 or later
  * Tor 0.2.0.1-alpha or later
 
-'''Assumptions:'''
+**Assumptions:**
  * Kernel IP forwarding is disabled
  * You don't want traffic to the internal LAN redirected through Tor
  * Your internal IP address is 192.168.1.1
- * Your outgoing network interface is {{{eth0}}} (could be wlan0 for wireless)
- * Your incoming network interface is {{{eth1}}} (For gateways and middleboxes)
+ * Your outgoing network interface is `eth0` (could be wlan0 for wireless)
+ * Your incoming network interface is `eth1` (For gateways and middleboxes)
  * Tor runs under UID 109
 
-== Checking for leaks ==
+## Checking for leaks
 
-You can use {{{tcpdump}}} to check if there are any internet activity other the Tor. In order to use it, you have to first identify your guard IP and your outgoing interface.
+You can use `tcpdump` to check if there are any internet activity other the Tor. In order to use it, you have to first identify your guard IP and your outgoing interface.
 
-To get your interface you can use {{{ip -o addr}}} or {{{tcpdump -D}}}.
+To get your interface you can use `ip -o addr` or `tcpdump -D`.
 
-We'll assume its {{{eth0}}}.
+We'll assume its `eth0`.
 
-Next you can use {{{ss}}}, {{{netstat}}} or {{{GETINFO entry-guards}}} through the tor controller to identify the guard IP.
+Next you can use `ss`, `netstat` or `GETINFO entry-guards` through the tor controller to identify the guard IP.
 
 Example:
-{{{ss -ntp | grep `cat /var/run/tor/tor.pid`}}}
+`ss -ntp | grep `cat /var/run/tor/tor.pid``
 
-With the interface and guard IP at hand, we can now use {{{tcpdump}}} to check for possible non-tor leaks. Replace IP.TO.TOR.GUARD with the IP you got from the {{{ss}}} output.
+With the interface and guard IP at hand, we can now use `tcpdump` to check for possible non-tor leaks. Replace IP.TO.TOR.GUARD with the IP you got from the `ss` output.
 
-{{{tcpdump -n -f -p -i eth0 not arp and not host IP.TO.TOR.GUARD}}}
+`tcpdump -n -f -p -i eth0 not arp and not host IP.TO.TOR.GUARD`
 
 You are not supposed to see any output other than the first two header lines. You can remove "and not host IP" to see how it would look like otherwise.
 
 ----
-=== Local Redirection Through Tor ===
+### Local Redirection Through Tor
 '''See also [[#WARNING]]!
 
 To enable the transparent proxy and the DNS proxy add the following to your torrc:
 
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
 DNSPort 5353
-}}}
+```
 
-Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying {{{/etc/resolv.conf}}}:
+Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying `/etc/resolv.conf`:
 
-{{{
+```
 nameserver 127.0.0.1
-}}}
+```
 
-Use the {{{nftables}}} or {{{iptables}}} ruleset below as an example. Read and understand the ruleset before applying!
+Use the `nftables` or `iptables` ruleset below as an example. Read and understand the ruleset before applying!
 
 NFTables
 
 
 /etc/nftables.conf
-{{{
+```
 # Verify your network interface with ip addr
 define interface = enp1s0
 # Verify tor uid with id -u tor
@@ -165,13 +165,12 @@ table ip filter {
                 ip daddr @private accept
         }
 }
-}}}
+```
 
 
 IPTables
 
-{{{
-#!/bin/sh
+```
 #
 
 ### Set variables
@@ -281,25 +280,24 @@ iptables -P OUTPUT DROP
 #ip6tables -P INPUT DROP
 #ip6tables -P FORWARD DROP
 #ip6tables -P OUTPUT DROP
-}}}
+```
 
 ----
-=== Anonymizing Middlebox ===
+### Anonymizing Middlebox
 '''See also [[#WARNING]]!
 
 To enable the transparent proxy and the DNS proxy, add the following to your torrc.
 
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 192.168.1.1:9040
 DNSPort 192.168.1.1:5353
-}}}
+```
 
-Use the {{{iptables}}} ruleset below as an example.
+Use the `iptables` ruleset below as an example.
 
-{{{
-#!/bin/sh
+```
 
 # Tor's TransPort
 _trans_port="9040"
@@ -313,33 +311,32 @@ iptables -t nat -F
 iptables -t nat -A PREROUTING -i $_inc_if -p udp --dport 53 -j REDIRECT --to-ports 5353
 iptables -t nat -A PREROUTING -i $_inc_if -p udp --dport 5353 -j REDIRECT --to-ports 5353
 iptables -t nat -A PREROUTING -i $_inc_if -p tcp --syn -j REDIRECT --to-ports $_trans_port
-}}}
+```
 
 ----
-=== Local Redirection and Anonymizing Middlebox ===
+### Local Redirection and Anonymizing Middlebox
 '''See also [[#WARNING]]!
 
 To enable the transparent proxy and the DNS proxy, add the following to your torrc.
 
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 192.168.1.1:9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
 TransPort 127.0.0.1:9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
 DNSPort 192.168.1.1:5353
 DNSPort 127.0.0.1:5353
-}}}
+```
 
-Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying {{{/etc/resolv.conf}}}.
+Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying `/etc/resolv.conf`.
 
-{{{
+```
 nameserver 127.0.0.1
-}}}
+```
 
-Use the {{{iptables}}} ruleset below as an example.
+Use the `iptables` ruleset below as an example.
 
-{{{
-#!/bin/sh
+```
 #
 
 ### Set variables
@@ -472,42 +469,42 @@ iptables -P OUTPUT DROP
 #ip6tables -P INPUT DROP
 #ip6tables -P FORWARD DROP
 #ip6tables -P OUTPUT DROP
-}}}
+```
 
 ----
-=== Transparently anonymizing traffic for a specific user ===
-'''Warning''': While this sounds great there is one disadvantage: ALL your dns request will be made through Tor. You anonymous ones and your non-anonymous ones. Not sure how safe it is to make first an anonymous DNS request and to non-anonymously view a target afterwards. '''See also [[#WARNING]]!
+### Transparently anonymizing traffic for a specific user
+**Warning**: While this sounds great there is one disadvantage: ALL your dns request will be made through Tor. You anonymous ones and your non-anonymous ones. Not sure how safe it is to make first an anonymous DNS request and to non-anonymously view a target afterwards. '''See also [[#WARNING]]!
  * Update: This may be outdated. You can use iptables to only redirect dns requests from the "anonymous" user and leave everything else as it is. See /etc/resolv.conf comments below.
- * Update (2014-02-07): There is a script which adds the relevant iptables rules [https://github.com/isislovecruft/scripts/blob/master/transproxy.firewall.sh here], though you will still need to set up the new user account and configure Tor as described below.
+ * Update (2014-02-07): There is a script which adds the relevant iptables rules [here](https://github.com/isislovecruft/scripts/blob/master/transproxy.firewall.sh), though you will still need to set up the new user account and configure Tor as described below.
 
 At first, we need to create a new user:
-{{{
+```
 useradd -m anonymous
-}}}
+```
 
 Then modify the torrc file:
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 9040
 DNSPort 53
-}}}
+```
 
 Restart Tor (this example is for Debian or Ubuntu):
-{{{
+```
 /etc/init.d/tor restart
-}}}
+```
 
 Then add some iptables rules (implementing some basic proxy functionality):
 
 iptables rules (iptables version >= 1.4.4):
-{{{
+```
 iptables -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner anonymous -m tcp -j REDIRECT --to-ports 9040
 iptables -t nat -A OUTPUT ! -o lo -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j REDIRECT --to-ports 53
 iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --dport 9040 -j ACCEPT
 iptables -t filter -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j ACCEPT
 iptables -t filter -A OUTPUT ! -o lo -m owner --uid-owner anonymous -j DROP
-}}}
+```
 Explanation: The first rule redirects HTTP (actually, TCP) traffic to the local port where TOR is listening. The second rule redirects DNS (actually, UDP) traffic to the local port 53 where TOR is listening for DNS queries. The last three rules block miscellaneous traffic (anything not TCP or DNS, such as UDP) that would not go through Tor, making sure that there is no leaking. The reason for the ACCEPT rules is that before iptables 1.4.2 it was possible to do this (e.g. DROP a packet) from the nat chain, but in higher version the DROP target is only available in the filter chain.
 
 WARNING: Ping (ICMP) is not blocked because ping packets have no "owner" the rule could match against. Either accept this as a risk for possible leaks or globally block ICMP with:
@@ -516,27 +513,26 @@ iptables -A OUTPUT -p icmp -j REJECT
 
 
 Tests show that for some reason this solution is still leaking DNS queries, so you can configure all DNS traffic to go through Tor on your computer:
-{{{
+```
 echo "nameserver 127.0.0.1" > /etc/resolv.conf
-}}}
+```
 Update: This may or may not be true, I suspect this was copied because there was a DNS leak when using NON_TOR exceptions. Those do not apply here. Better leave resolv.conf as it is (but test for leaks). Otherwise the warning about mixing clear text and tor DNS requests does apply!
 
 
 Now you can run apps with sudo and they will be magically anonymized:
-{{{
+```
 sudo -H -u anonymous irssi
-}}}
+```
 
 If you want to make the iptables rules permanent you have to make sure they are executed at startup time, for example by adding a script in the right directory. On Debian/Ubuntu you can do something like this:
-{{{
+```
 sudo touch /etc/init.d/anonuser
 sudo chmod a+x /etc/init.d/anonuser
 sudo vim /etc/init.d/anonuser
-}}}
+```
 
 Enter the following into a script that will generate iptables rules:
-{{{
-#!/bin/sh
+```
 # I learned this from https://wiki.torproject.org/noreply/TheOnionRouter/TransparentProxy
 # It's for running applications as user "anonymous", without proxy servers, through Tor.
 iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp -j REDIRECT --to-ports 9040
@@ -544,103 +540,103 @@ iptables -t nat -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 5
 iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --dport 9040 -j ACCEPT
 iptables -t filter -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j ACCEPT
 iptables -t filter -A OUTPUT -m owner --uid-owner anonymous -j DROP
-}}}
+```
 
 To use Vidalia to control Tor over Tor's control port, you'll want the following rule (assuming your Tor control port is on 127.0.0.1:9051):
-{{{
+```
 iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --syn -d 127.0.0.1 --dport 9051 -j ACCEPT
-}}}
+```
 
 A very simple set of rules with a functional Vidalia might look like the following:
-{{{
+```
 iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --syn -d 127.0.0.1 --dport 9051 -j ACCEPT
 iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --syn -j REDIRECT --to-ports 9040
 iptables -t nat -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j REDIRECT --to-ports 53
 iptables -t nat -A OUTPUT -m owner --uid-owner anonymous -j DROP
-}}}
+```
 
 ----
-=== Transparently Doing DNS and Routing for .onion Traffic ===
+### Transparently Doing DNS and Routing for .onion Traffic
 
-'''Warning''': While this sounds great there is one disadvantage: ALL your dns request will be made through Tor-- anonymous and non-anonymous. This can slow down accessing webpages (since you will not be directed to the server closest to your location) that you are not accessing anonymously. '''See also [[#WARNING]]!
+**Warning**: While this sounds great there is one disadvantage: ALL your dns request will be made through Tor-- anonymous and non-anonymous. This can slow down accessing webpages (since you will not be directed to the server closest to your location) that you are not accessing anonymously. '''See also [[#WARNING]]!
 
 This method works for all users, and allows software you don't want to run through a proxy to use .onion addresses to access hidden services. Traffic to non-.onion addresses is left alone.
 
 Add the following lines to the torrc file:
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 9040
 DNSPort 53
-}}}
+```
 
 This sets up Tor to resolve DNS, and gives it a network to map .onion addresses on to. (If you're using 10.192 for something, use a different 10. address.) It also sets port 9040 as the tor Transport port (separate from any proxy port.)
 
 Modify /etc/resolv.conf as follows:
-{{{
+```
 nameserver 127.0.0.1
-}}}
+```
 
 This tells all DNS queries to go through Tor. (Remove any existing entries.)
 
 Finally, one iptables rule:
-{{{
+```
 iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040
-}}}
+```
 
 This tells iptables to transparently redirect any traffic destined for the Tor virtual address space through the Tor transport port you designated above.
 
 Now any .onion addresses will be resolved, mapped into the 10.192/10 space, and transported through Tor, while leaving all non-.onion addresses alone! Interoperability reigns.
 
 ----
-== BSD (PF) ==
+## BSD (PF)
 
-'''Warning''': ALL your DNS request will be made through Tor -- anonymous and non-anonymous. This can slow down accessing webpages that you are not accessing anonymously.
+**Warning**: ALL your DNS request will be made through Tor -- anonymous and non-anonymous. This can slow down accessing webpages that you are not accessing anonymously.
 
-'''Assumptions:'''
+**Assumptions:**
  * kernel IP forwarding is disabled
  * you don't want traffic to 192.168.1.0/24 and 192.168.0.0/24 redirected through Tor
- * your internal network interface is {{{fxp0}}}
- * '''/dev/pf is readable (OpenBSD) or readable and writable (other BSDs) by Tor (if you are running Tor in a chroot, you must also have /dev/pf inside the chroot)'''
+ * your internal network interface is `fxp0`
+ * **/dev/pf is readable (OpenBSD) or readable and writable (other BSDs) by Tor (if you are running Tor in a chroot, you must also have /dev/pf inside the chroot)**
 
-=== Local Redirection Through Tor ===
+### Local Redirection Through Tor
 
 To enable the transparent proxy and DNS proxy, add the following to your torrc.
 
-{{{
+```
 AutomapHostsOnResolve 1
 TransPort 9040
 DNSPort 53
-}}}
+```
 
-Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying {{{/etc/resolv.conf}}}.
+Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying `/etc/resolv.conf`.
 
-{{{
+```
 lookup file bind
 nameserver 127.0.0.1
-}}}
+```
 
-If dhclient is rewriting your {{{/etc/resolv.conf}}} file, add the following line to {{{/etc/dhclient.conf}}} and (only on OpenBSD?) invoke {{{sh /etc/netstart}}}:
+If dhclient is rewriting your `/etc/resolv.conf` file, add the following line to `/etc/dhclient.conf` and (only on OpenBSD?) invoke `sh /etc/netstart`:
 
-{{{
+```
 supersede domain-name-servers 127.0.0.1;
-}}}
+```
 
 As root, create a second loopback interface.
 
-{{{
+```
 ifconfig lo1 create up 127.0.0.2
-}}}
+```
 
 Configure the interface when netstart is invoked (at startup) in OpenBSD:
 
-{{{
+```
 # echo "inet 127.0.0.2" > /etc/hostname.lo1
-}}}
+```
 
 Use the PF ruleset below as an example for FreeBSD & OpenBSD prior to 4.7.
 
-{{{
+```
 # destinations you don't want routed through Tor
 non_tor = "{ 192.168.1.0/24 192.168.0.0/24 }"
 
@@ -665,11 +661,11 @@ pass out quick inet proto tcp user _tor flags S/SA modulate state
 pass out quick route-to lo1 inet proto udp to port domain keep state
 pass out quick inet to $non_tor keep state
 pass out route-to lo1 inet proto tcp all flags S/SA modulate state
-}}}
+```
 
 Use the PF ruleset below as an example for OpenBSD 4.7 and later.
 
-{{{
+```
 # destinations you don't want routed through Tor
 non_tor = "{ 192.168.1.0/24 192.168.0.0/24 }"
 
@@ -696,24 +692,24 @@ pass out quick inet proto tcp user _tor flags S/SA modulate state
 pass out quick inet proto udp to port domain route-to lo1
 pass out quick inet to $non_tor
 pass out inet proto tcp all route-to lo1
-}}}
+```
 
 ----
 
-=== Anonymizing Middlebox ===
+### Anonymizing Middlebox
 
 To enable the transparent proxy and the DNS proxy, add the following to your torrc.
 
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 9040
 DNSPort 53
-}}}
+```
 
 Use the PF ruleset below as an example for FreeBSD and OpenBSD prior to 4.7.
 
-{{{
+```
 # your internal interface
 int_if = "fxp0"
 
@@ -726,11 +722,11 @@ scrub in
 
 rdr pass on $int_if inet proto tcp to !($int_if) -> 127.0.0.1 port $trans_port
 rdr pass on $int_if inet proto udp to port domain -> 127.0.0.1 port domain
-}}}
+```
 
 Use the PF ruleset below as an example for OpenBSD 4.7 and later.
 
-{{{
+```
 # your internal interface
 int_if = "fxp0"
 
@@ -743,49 +739,49 @@ match in all scrub (no-df random-id)
 
 pass in quick on $int_if inet proto tcp to !($int_if) rdr-to 127.0.0.1 port $trans_port
 pass in quick on $int_if inet proto udp to port domain rdr-to 127.0.0.1 port domain
-}}}
+```
 
 ----
 
-=== Local Redirection and Anonymizing Middlebox ===
+### Local Redirection and Anonymizing Middlebox
 
 To enable the transparent proxy and the DNS proxy, add the following to your torrc.
 
-{{{
+```
 VirtualAddrNetworkIPv4 10.192.0.0/10
 AutomapHostsOnResolve 1
 TransPort 9040
 DNSPort 53
-}}}
+```
 
-Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying {{{/etc/resolv.conf}}}.
+Configure your system's DNS resolver to use Tor's DNSPort on the loopback interface by modifying `/etc/resolv.conf`.
 
-{{{
+```
 lookup file bind
 nameserver 127.0.0.1
-}}}
+```
 
-If dhclient is rewriting your {{{/etc/resolv.conf}}} file, add the following line to {{{/etc/dhclient.conf}}} and (only on OpenBSD?) invoke {{{sh /etc/netstart}}}:
+If dhclient is rewriting your `/etc/resolv.conf` file, add the following line to `/etc/dhclient.conf` and (only on OpenBSD?) invoke `sh /etc/netstart`:
 
-{{{
+```
 supersede domain-name-servers 127.0.0.1;
-}}}
+```
 
 As root, create a second loopback interface.
 
-{{{
+```
 ifconfig lo1 create up 127.0.0.2
-}}}
+```
 
 Configure the interface when netstart is invoked (at startup) in OpenBSD:
 
-{{{
+```
 # echo "inet 127.0.0.2" > /etc/hostname.lo1
-}}}
+```
 
 Use the PF ruleset below as an example for FreeBSD and OpenBSD prior to 4.7.
 
-{{{
+```
 # your internal interface
 int_if = "fxp0"
 
@@ -808,11 +804,11 @@ pass out quick inet proto tcp user _tor flags S/SA modulate state
 pass out quick route-to lo1 inet proto udp to port domain keep state
 pass out quick inet to $non_tor keep state
 pass out route-to lo1 inet proto tcp all flags S/SA modulate state
-}}}
+```
 
 Use the PF ruleset below as an example for OpenBSD 4.7 and later.
 
-{{{
+```
 # your internal interface
 int_if = "fxp0"
 
@@ -835,15 +831,15 @@ pass out quick inet proto tcp user _tor flags S/SA modulate state
 pass out quick inet proto udp to port domain keep state route-to lo1
 pass out quick inet to $non_tor keep state
 pass out inet proto tcp all flags S/SA modulate state route-to lo1
-}}}
+```
 
 ----
 
-== Using firehol in linux ==
+## Using firehol in linux
 
 On any system running iptables (Linux) you can use firehol if you are uncomfortable using iptables edit your /etc/firehol/firehol.conf to show:
 
-{{{
+```
 server_tor_ports="tcp/9050 tcp/9051"
 client_tor_ports="default"
 server_proxy_ports="tcp/9040"
@@ -889,6 +885,6 @@ interface lo internal src 127.0.0.1 dst 127.0.0.1
 interface eth1 subnet src 192.168.2.0/24 dst any
 	server dns accept
 	server torproxy accept
-}}}
+```
 
 Pick and choose which portions are right for you as not all lines are necessary in all situations.
\ No newline at end of file