I worked for 12 years at corporations and I’ve seen it all. One of the worst inventions was the corporate HTTP proxy, which is introduced with good intentions — to harden the company’s security position, to monitor your activities, to block data exfiltration and so on.
In this post I’ll show you how to bypass the proxy to gain unfettered Internet access without censoring. I’ll also cover some of the common issues such as blocked ports, LDAP authentication and tools of the trade.
The risks and rewards
Follow this guide at your own risk, and if you attempt to circumvent your company’s policy, then you may be in breach of your contract, or worse get dismissed.
If the risks are so high, then why am I showing you this approach?
- Not every proxy you find will be at a corporation, you may find that a coffee shop, hotel, airport, or guest WiFi blocks sites you need to access.
- These policies often leak into networks that have little risk to the company like guest/visitor and BYOD networks.
- Your government, or university, or another institution may be blocking your access to certain news or social media sites.
What are we dealing with?
There are a number of techniques we can apply here depending on the severity of the firewall and proxy being employed.
A typical corporate network looks like this:
- No outgoing connections on anything but TCP ports 80 and 443
- No outgoing connections except via a HTTP proxy
- The HTTP proxy must authenticate with LDAP (Active Directory)
All of these in combination make life harder for accessing blocked sites, common examples are:
- Google Mail / Drive — for fear of data exfil
- Slack — for fear of distractions and data exfil
- GitHub — risks of open source distractions and data exfil
- S3 — yes, the Internet relies on access to S3, tools like Slack and Flowdock (“enterprise chat”) upload assets there, and are often blocked
A common theme here? What else do you struggle to access at work?
Approach 1 — the SSH tunnel
In approach 1 we assume the following:
- Direct connections over SSH are allowed on port 22
- You have access to a VPS or cloud provider where you can create VMs with public IPs
- You can connect to those public IPs from your laptop
First, create a new VM either off-site (if blocked), or via the proxy if it is not blocked. I would recommend using an LTS version of Ubuntu with SSH enabled. Note down the IP, you will need it for later
I recommend that you setup a DNS A record to point to the IP of your domain such as
tunnel.example.com. Domains can be purchased from 2–15 USD from namecheap.com, but try not to use a weird extension like
.space as your network will probably see these as suspicious.
Next install Docker on the host as a non-root user i.e.
curl -sLS https://get.docker.com | sudo sh
usermod -aG admin docker
Now that we have Docker installed, we’ll be running Squid. Squid is a HTTP proxy and it will receive requests from our local computer and request webpages on our behalf.
We will run squid within a Docker on the VM. It is very important for you to remember, instead expose it only to localhost (127.0.0.1).
Do not expose squid to the Internet
You can find my Dockerfile on GitHub, and are free to rebuild it from source if you would like to do that.
docker run -p 127.0.0.1:3128:3128 \
--name squid \
--restart always \
This effectively restarts squid on demand and runs it on a private port.
Now connect your laptop or local machine to the VM over SSH, with a port forwarding rule. If you do not have a Mac or Linux PC, then install Git Bash on Windows 7 or 10, so that you can get access to
This will not expose your proxy to the local LAN / network, but only to your local machine.
ssh -L 3128:127.0.0.1:3128 admin@remote-ip
You now have a tunnel from your laptop to the VM on your IaaS, with uncensored, unfettered access to the Internet.
You can try the tunnel using
curl, which is a built-in command with most Macs, Linux computers and with Git bash.
Let’s try to access slack.com, a common site that is often blocked:
curl -x http://127.0.0.1:3128 https://slack.com/
Now check what your IP is. Amazon provide a website for this, but others also exist, you can find them on Google.
Now if you want o set-up your browser to use the proxy, simply open the settings for your browser.
Issues with this approach
Port 22 is blocked for outgoing traffic
If outgoing SSH is blocked on port 22, then you should edit
/etc/ssh/sshd_config and add a line such as
Port 443 and restart the machine.
All traffic must go through the proxy
ProxyCommand /usr/bin/proxytunnel -p some-proxy:8080 -d www.muppetzone.com:443
You must authenticate with LDAP to your proxy
This configuration is the hardest to work with, but there is hope. You can use an open source tool called cntlm to authenticate to your proxy.
If you decide to bypass a proxy or corporate firewall, then you do this at your own risk, and the punishment could be severe.
This is not the only approach for bypassing a HTTP proxy, but is certainly one of the quickest and simplest to conifgure. Most of the time, the approach I outlined in this post will be sufficient, and if it is not, then you may want to explore alternatives such as using a mobile hotspot.
Tunnels with Inlets / Inlets PRO
Inlets and Inlets PRO provides a way of doing something slightly different, you can expose a local endpoint on the Internet, instead of reaching blocked Internet sites. If you’ve heard of Ngrok, then that is a similar tool but often blocked because it cannot be self-hosted.
Why might you want to do that? You may be testing webhooks from GitHub, PayPal, Slack, or an integration with a partner’s data-feed or API. You may have a server which you want to access via SSH from the Internet, but you don’t want to manage a complicated VPN or to pay for AWS Direct Connect.
Inlets provides a HTTP tunnel, which can be configured with HTTPS.
Inlets PRO provides a TCP tunnel which has automatic TLS (encryption) configured by default and is able to tunnel HTTPS, SSH, databases and more.
As before, you are advised to seek permission to use any tunnelling tools and you access any of this information at your own risk.
For comments, questions and suggestions please feel free to reach me on Twitter Alex Ellis