I'm trying to set up a transparent proxy on my Mac OS X Lion (10.7.5), so I can use mitmproxy (to intercept SSL traffic from android applications). I followed the steps in the mitmproxy docs for setting up port forwarding with pf on Mac OS X, and they all went without any errors:
$ sudo sysctl -w net.inet.ip.forwarding=1
Password:
net.inet.ip.forwarding: 0 -> 1
$ sudo pfctl -f pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
But it doesn't seem to have had any effect. When I go to websites in my browser, it makes a direct request, and doesn't go through the port I specified. Here is the pf.conf
file (en1
is my wifi):
rdr on en1 inet proto tcp to any port 80 -> 127.0.0.1 port 4500
rdr on en1 inet proto tcp to any port 443 -> 127.0.0.1 port 4500
Did you try
net.inet.ip.scopedroute=0
? From http://lucumr.pocoo.org/2013/1/6/osx-wifi-proxy/:You are using the port 4500 instead the default port 8080. Do you start mitmproxy with the port specification?: mitmproxy -T --host -p 4500
Did you follow the steps to set the certificate in the Android device? http://mitmproxy.org/doc/certinstall/android.html
Another problem could be the gateway on your android phone: Preferences - Wifi - Hold on the network you are using - Edit network - Advanced options - Set as gateway the ip of your machine with mitmproxy.
By the way I have the same warning with No ALTQ function but it works.
Thanks for stopping by the IRC channel today. I've tracked this down, and the basic issue is that the rdr rules apply to inbound traffic. This means that they will NOT redirect traffic coming from the box itself. If you think about it, this is inevitable: we can't distinguish between an outbound connection from a non-mitmproxy app, and an outbound connection from mitmproxy itself. We can use route-to to send the traffic to lo0 and then redirect it, but that causes an infinite loop where mitmproxy's own outbound connections are also redirected back to mitmproxy.
Because I know a bit about your use case, I would suggest exploring ways to do this with VirtualBox. A plan of attack would be to set the VirtualBox network up in bridge mode, and then use a pf rule with a match on the source address to redirect traffic to mitmproxy. That should do what you want, and not cause singularities in time and space due to infinite redirection.
Please drop by the IRC channel again if you need a further hand with this.