You ever wonder how Charles Proxy gets all of the HTTP/HTTPS traffic on the box? I probably should research this more, but I suspect that it sets itself up as the system proxy. Any client that respects the outbound proxy configured on the OS will use the outbound proxy and be visible to Charles. However there are those that do not - for instance curl
doesn't get caught by Charles (unless you somehow tell curl to use a proxy, such as --proxy or -x or setting http_proxy, etc.).
And so, with a non-transparent proxy like Charles, you'll have to rely on client behavior.
Fortunately, a lot of applications do respect the outbound proxy set at the system level (and many applications also allow you to specify an application configuration as well). And so, by setting the outbound proxy system proxy, you can get a lot of your applications (certainly browsers) to go through Charles.
If you have admin access to the hosts using Internet Sharing on your network you might as well set the client's system outbound proxy to point to your Charles proxy.
And one more thing - when I performed this configuration, Charles Proxy wanted me to manually Accept the connection. Charles is ok with connections made to localhost, but when the client is coming from another box, you have to manually Accept the connection. Charles only prompted me once per host.
Another thought on this: there are network mechanisms for setting the outbound proxy on your client computers. Systems can learn the outbound proxy from their DHCP query (when they ask the network for their dynamically assigned IP address). Does MACOS allow you to specify the outbound proxy when doing internet connection sharing? I don't know, that's how I found your post. I am currently looking for a way to configure Internet Connection Sharing to also provide clients with the outbound proxy.
However, if your internet sharing doesn't allow you to specify the outbound proxy, it's probably not worth pursuing the automatic approach and stick with manual configuration on each sharing client.
Even more obscure than the DHCP approach is the WPAD approach. WPAD, or Web Proxy Auto-Discovery, is a technology that allows browsers to discover the outbound proxy (a bit of an over simplification because it actually can supply conditional logic for finding multiple outbound proxies). WPAD is probably only for web browsers (but I suppose any client that is javascript capable may use it). There is a lot to read about WPAD, but unless you have control over DNS in your system it's probably not a viable solution for you.
As long as I am going off topic, I have an associate who ran raspberry pi with the equivalent of internet connection sharing on it. The pi device was also running bind (a DNS server) and dns-masq so that it could intercept some of the DNS queries and return its own IP address. And lastly, it was running an HTTP(S) proxy. So the clients would unknowingly send the proxy requests that would then be proxied on their behalf to the intended URLs. And that's how my colleague avoided having to set up outbound proxies on the clients.
iptables
, like this. I’m not familiar with OS X’ firewall, but this is basically what you’ll have to replicate.