One of my friend contacted me regarding an issue where the client had provided a locked-down, shared VDI environment, which was also being accessed by another vendor, to the point where he was occasionally disconnected mid-session.

Despite these constraints, the assessment had to proceed under the following conditions:

He asked a simple question:

Is there any way I can still use my own Burp Pro locally, without activating it on the client VDI?

Since I enjoy learning and experimenting with new approaches, I decided to explore this problem during some free time over the New Year period.

This post documents the exact setup we ended up using.

The Core Idea

We want three things:

To solve this, we introduce a small EC2 relay server and use SSH port forwarding to stitch the environments together.

Client VDI ←→ EC2 Relay ←→ Tester Machine (Burp Pro)

Why SSH on Port 443?

Here’s the first hurdle we hit.

Port 22 (SSH) was blocked outbound from the VDI. This is extremely common in corporate environments. However, port 443 was allowed.

SSH doesn’t care what port it runs on, so we simply configured all tunnels to use port 443, which blends in with normal HTTPS traffic and avoids firewall issues entirely.

Step 1 — EC2 SSH Configuration (Critical)

By default, Amazon Linux disables remote port forwarding. Without fixing this, nothing below will work.

On the EC2 instance:

sudo nano /etc/ssh/sshd_config.d/99-portforward.conf

Add:

AllowTcpForwarding yes
GatewayPorts yes

Restart SSH:

sudo systemctl restart sshd

This allows ports forwarded from other machines to be exposed via EC2.

Step 2 — Local Machine (Burp Suite Professional)

Burp Pro runs only on the tester’s local machine.

Expose Burp Pro to EC2 (Reverse Forward):

ssh -i RelayServer.pem -p 443 -N -R "*:9001:127.0.0.1:8080" ec2-user@IPAddress -vvv

This makes Burp Pro (listening on 8080) available as:

EC2:9001 → Mac:8080 (Burp Pro)

Allow Burp Pro to send traffic back via EC2 (Local Forward):

ssh -i RelayServer.pem -p 443 -N -L 8888:127.0.0.1:8080 ec2-user@IPAddress -vvv

This lets Burp Pro send traffic back through EC2, ensuring requests ultimately exit from the VDI network.

Step 3 — Client VDI

On the VDI, we run Burp Suite Community only as a lightweight proxy endpoint.

SSH Tunnel from VDI:

ssh -i RelayServer.pem -p 443 -N -L 8081:127.0.0.1:9001 -R 8080:127.0.0.1:8080 ec2-user@IPAddress

What this does:

Step 4 — Burp Configuration

Burp Suite Professional (Local Machine)

The figure below shows Burp Pro (Local Machine) is configured with upstream proxy:

Burp Pro never connects directly to the target application. All requests ultimately exit the VDI network.

Burp Suite Community (VDI)

The figure below shows Burp Suite configured:

Burp Suite Community on the VDI is used purely as a lightweight proxy endpoint.
No analysis, scanning, or modification is performed here.

Note: Do not use Burp’s embedded browser

Firefox on the VDI

Configure Firefox manually:

This way:

Now the browser flow is:

Firefox (VDI) → EC2 → Burp Pro (Mac) → EC2 → Burp Community (VDI) → Target

The figure below shows that Burp Pro (Local Machine) is receiving all the traffic:

Lessons Learned

Final Thoughts

This setup has now been used successfully for:

If you ever feel uneasy about activating your Burp Pro license on a client machine, this is a clean, professional alternative.

And yes, my friend was very happy (I got a coffee from him ☕).

Disclaimer: It is highly recommended to consult with the client to ensure they are comfortable with the use of an EC2 relay, as the traffic will be routed through an AWS environment.