Kali ARM64 on UTM (Apple Silicon): Fix Burp “Browser Not Available” + Set Up an External Firefox Proxy

“Browser Not Available” on Apple Silicon: Stop Guessing, Start Intercepting

This error can steal half an hour before your first request ever hits Proxy history. In a Kali ARM64 VM on UTM (Apple Silicon), that message typically means Burp Suite can’t spawn its embedded browser helper—Java runtime libraries or the desktop session—even though the proxy engine itself is perfectly fine.

The trap is treating it like a port problem and endlessly toggling settings. Keep guessing and you lose the only thing labs never refund: momentum.

The Solution: Get back to clean interception fast. Separate the proxy path from TLS trust and browser launch. Do not rely on folklore or random port changes. Validate each layer with one deliberate test.

A Calm, Repeatable Setup:

1. Get traffic into Burp first

2. Make Firefox trust the CA second

3. Worry about the embedded browser last

Who this is for / not for (so you don’t waste an evening)

For: US-based pentest/CTF learners and working web testers on Apple Silicon who run Kali ARM64 in UTM and need Burp Suite to behave like an adult: intercept HTTPS, run proxy history, and repeat tests without random breakage. If you’re juggling study with real life, the 2-hour-a-day OSCP routine mindset applies here too: prove one layer at a time, and don’t romanticize suffering.

Not for: If you’re planning to run a full x86-only toolchain, need Windows-only browser plugins, or want to test with Chrome policies tied to an enterprise domain, you’ll have fewer headaches using a different setup. Also, if your goal is “just intercept macOS Safari,” there are native ways to do that without a VM. If you’re still choosing your platform, it helps to understand Kali vs Parrot vs BlackArch for VM-based pentesting and how that choice changes day-to-day friction.

Your “good enough” target setup (what success looks like in 2 minutes):

• Burp Suite launches cleanly and the Proxy listener is active.
• Firefox (inside Kali) is explicitly configured to use Burp as an HTTP/HTTPS proxy.
• You can load a single HTTPS page and see it in Proxy history without certificate drama.

Personal note: the first time I hit “Browser Not Available,” I lost 30 minutes blaming my proxy port. It was my ego, not the config.

The symptom decoded: what “Browser Not Available” usually means on ARM

On Kali ARM64 in UTM, Burp’s “Browser Not Available” rarely means “Burp can’t proxy.” It means Burp’s embedded browser launch mechanism can’t start a component it expects to exist—often because the install method brought a mismatched Java runtime, a missing GUI library, or a helper binary that doesn’t play nicely in your current desktop/session environment.

The three common root causes:

• Install source mismatch: a distro-packaged build or wrapper behaves differently than the official installer.
• Java runtime mismatch: Burp depends on a compatible Java environment; “any Java” is not a promise.
• Missing GUI/runtime libraries: the desktop stack (and certain libs) can be absent on slim Kali images.

Quick fingerprint (1-minute checks):

• Does Burp itself start without errors, or does it complain about Java immediately?
• Does the Proxy listener show “running,” and can you hit the built-in CA page?
• Is your Kali desktop session stable (not half-configured, not missing basic GUI bits)?

Curiosity gap: why it fails after it “worked once.” Updates can quietly change the Java default, alter library versions, or reset paths. The VM didn’t betray you. It just stopped tolerating a shaky chain.

Show me the nerdy details

Burp’s embedded browser is not “just a tab.” It’s a launch pipeline that depends on the runtime (Java), the desktop session (Wayland/Xorg behaviors), and the presence of expected libraries. On ARM VMs, small mismatches can show up as “not available” even when Burp’s proxy core is fine.

Install reality check: the Burp build you chose matters more than your proxy

There are two broad ways people end up with Burp on Kali: an official build from PortSwigger, or a distro/apt version (or a wrapper). On ARM VMs, the official route is usually the most predictable because it’s designed to ship with the assumptions Burp expects.

Option A: Official Burp release (most predictable on ARM VMs)

If you can choose only one thing to “standardize” in your setup, standardize the install source. In practice, the official installer reduces the weird edge cases around Java packaging and helper components.

Option B: Distro/apt versions (where surprises creep in)

Package-managed versions can be convenient, but convenience sometimes comes with “creative” dependencies. When something breaks, you’re debugging the package ecosystem, not Burp.

Java runtime sanity: which Java version and why Burp cares

Burp runs on Java, but Java versions are not interchangeable in real life. If your Burp build expects a certain baseline and your system defaults to another, you can get launch issues that look unrelated—like a missing browser.

Let’s be honest… the “easy install” is often the one that breaks first (and why)

I’ve watched “works on my machine” turn into “why won’t it open” after a single apt upgrade. If you’re time-poor, stable beats clever.

Practical operator move: pick one install method and stick to it. If you switch methods mid-troubleshoot, you can end up with mixed configs, mixed launchers, and the special kind of confusion that feels personal.

UTM prerequisites that quietly decide whether Burp’s browser can launch

UTM is usually not the villain here—but your desktop session inside Kali and your VM’s “quality of life” settings can decide whether helper processes behave. Burp’s embedded browser is a helper process problem dressed up as a Burp problem.

Display server basics (Wayland vs Xorg) and why GUI apps behave differently

Some Kali images default to Wayland, some to Xorg, and some live in a half-configured middle where things “mostly work.” Burp’s UI can appear fine while embedded helpers quietly fail. If your desktop session is unstable, fix that first.

Clipboard/graphics spice: when “it’s sluggish” becomes “it won’t open”

Sluggish graphics isn’t just an annoyance. When the VM struggles to spawn windows or handle focus properly, embedded browser launching can fail in ways that look like missing software.

Curiosity gap: the one UTM choice that makes your VM feel fine—but breaks launching helpers

Here’s the sneaky part: a VM can feel smooth and still block a helper if permissions, paths, or desktop services aren’t fully present. The surface is calm; the plumbing is not. If you’re building a setup you can trust long-term, a structured approach like Kali Linux lab infrastructure mastery helps you avoid “fast today, fragile tomorrow.”

Personal note: I once “optimized” a Kali VM by stripping packages to make it fast. Burp got fast too—fast at refusing to launch anything helpful.

Show me the nerdy details

On minimal images, you can end up missing shared libraries that GUI helpers assume exist. The core app launches, but a secondary component (like an embedded browser helper) fails at runtime. This is why “the UI opens” is not the same as “the feature stack works.”

Fix path #1: make Burp’s built-in browser available again (the clean sequence)

If you want the built-in browser, don’t treat this like a guessing contest. Treat it like a chain: Burp → runtime → helper → desktop. Fix the chain in order, and validate after each move.

Step 1: Confirm Burp can spawn helper processes (permissions + paths)

Run Burp from a terminal once, even if you normally click an icon. You want to see any launch output that the GUI hides. If Burp can’t spawn a helper process, the terminal often tells you first.

Step 2: Verify required libraries are present (the usual missing pieces)

If you’re on a slim image, install the missing GUI/runtime libraries your desktop expects. Don’t install the entire internet—install what fixes the symptom. If you notice other GUI apps failing to open or render, that’s your hint.

Step 3: Reset Burp user config (when stale state blocks launching)

Burp’s user configuration can get stale, especially after upgrades. A reset is not “nuking your life”—it’s a controlled diagnostic step. Back up your Burp config folder, then let Burp rebuild clean state.

Step 4: Validate by launching the built-in browser before you touch certificates

Certificates are a separate layer. If the built-in browser still won’t launch, a certificate fix will not magically teach a helper process to exist.

Short Story: I once tried to “fix” Burp by changing proxy ports, listeners, and browser settings—everything except the real culprit. The embedded browser kept refusing to launch, and I took it personally, like a rejection letter. Eventually I ran Burp from a terminal and saw the quiet truth: a helper process couldn’t start because a dependency was missing.

Five minutes later, after installing the right library and rebooting the desktop session, the browser appeared like it had been there the whole time. The lesson wasn’t technical. It was psychological: don’t negotiate with the symptom. Ask the system what it needs, then give it exactly that—no more, no less. (About 150 words.)

Fix path #2: skip the built-in browser—use an external Firefox (more stable for labs)

If your goal is web testing—not “making Burp’s internal browser feel loved”—external Firefox is often the best path on ARM VMs. It’s stable, debuggable, and it doesn’t depend on Burp’s embedded launch pipeline. This is the route I use when I’m trying to finish a lab instead of auditioning for a troubleshooting documentary. If your work involves modern app traffic, you’ll also appreciate a separate, repeatable workflow for Burp Suite WebSocket interception and debugging—because “it loads” and “it behaves” are not always the same thing.

Why external Firefox is often the “adult choice” on ARM VMs

• Firefox’s proxy settings and certificate store are explicit and inspectable.
• You can isolate problems: proxy vs TLS vs DNS behavior.
• It behaves consistently across VM environments.

Choose your interception model: transparent-ish vs explicit proxy (and what’s realistic here)

In a Kali VM, explicit proxy is your friend. Transparent interception is possible in some setups, but it introduces extra moving parts (iptables rules, routing assumptions, and a longer list of ways to be disappointed).

Curiosity gap: the “invisible proxy” problem—why traffic bypasses Burp even when Firefox looks set

The classic: you set a proxy, refresh a page, and Burp stays quiet. The cause is usually one of these:

• Firefox is bypassing proxy for “localhost” or a domain list.
• DNS-over-HTTPS or a network feature changes where resolution happens.
• You pointed Firefox to 127.0.0.1 but Burp is not reachable at that address in your topology.

External Firefox proxy setup (the exact settings that don’t lie)

This section assumes Firefox is running inside your Kali VM and Burp is running in the same VM. That’s the simplest, most reliable topology. When you split Burp and the browser across host/guest, you can do it—but you’ll need to think harder about bind addresses and routing.

Set HTTP/HTTPS proxy to Burp listener (host/port) + “Use this proxy for all protocols”

In Firefox:

• Open Settings → search for proxy → Network Settings → Settings…
• Select Manual proxy configuration
• Set HTTP Proxy to your Burp listener (commonly 127.0.0.1 and 8080 if Burp is on the same VM)
• Check “Also use this proxy for HTTPS”

DNS + proxy behavior: when name resolution makes you think proxy is broken

If you’re using DNS-over-HTTPS in Firefox, it can change the “shape” of traffic in ways that confuse troubleshooting. You don’t need to permanently disable it, but for debugging, simplify the system so your evidence is clean. If you want a practical mental model for “proxy is set but names resolve somewhere else,” the same logic shows up in proxychains DNS leak fixes—different tool, same kind of invisible bypass.

Quick test: one request that proves interception (and one that proves TLS trust)

• Proxy proof: Load any HTTP page (not HTTPS) and confirm it appears in Burp Proxy history.
• TLS trust proof: Load an HTTPS page and confirm it appears without certificate warnings after you install Burp’s CA.

Personal note: I always test HTTP first. It’s not because I love HTTP. It’s because I love finishing tasks.

Show me the nerdy details

HTTP is a clean “is the proxy path working?” test. HTTPS adds a second layer (certificate trust). If you test HTTPS first, you can’t tell whether you have a proxy problem or a trust-store problem. Two tests beat one confusing test.

Certificates without regret: install Burp CA into Firefox the safe way

To intercept HTTPS without warnings, Firefox needs to trust Burp’s CA certificate. And here’s the key: Firefox maintains its own certificate store in many setups. Trusting something at the OS level does not guarantee Firefox trusts it.

Get the CA from the right place (Burp’s built-in endpoint) and don’t overcomplicate it

With Burp running and your proxy set, visit Burp’s built-in CA download page (Burp provides it via the proxy). Download the CA certificate file.

Import into Firefox Certificate Manager (Authorities) + the one checkbox that matters

In Firefox, open the Certificate Manager, import the certificate under Authorities, and ensure you allow it to trust websites (the exact wording varies slightly by Firefox version). If you miss that checkbox, you’ll get HTTPS warnings that feel unfair because you “already imported it.”

Here’s what no one tells you… system trust ≠ Firefox trust (why your HTTPS still fails)

This is the trap. You did a reasonable thing (installing a cert) and the browser still complains. It’s not mocking you. It’s using a different trust store than you assumed.

Common mistakes (the ones that cost the most time)

These mistakes are common because they’re reasonable. They’re also expensive because they produce symptoms that look like something else. Read this like a checklist you run when you’re tired and your coffee is lying to you.

Mistake #1: Pointing Firefox at 127.0.0.1 when Burp isn’t on that same “localhost”

If Burp and Firefox are on different machines (host vs VM, or another device), 127.0.0.1 points to the wrong place. Use the reachable IP and ensure Burp’s listener binds appropriately.

Mistake #2: Importing the cert into the OS store and assuming Firefox will follow

Sometimes it will. Often it won’t. In a lab setup, assume Firefox needs its own import unless you’ve proven otherwise.

Mistake #3: Changing Burp listener bind address without realizing what it did

Binding to 127.0.0.1 is safe and simple for same-VM usage. Binding to 0.0.0.0 can expose Burp to other network interfaces. Do it only when you need it, and only when you understand what can reach it.

Mistake #4: Testing with HSTS-heavy sites first (false negatives)

Some sites are aggressive about HTTPS and can behave strangely through interception. Start with a simpler test target to prove your path.

Mistake #5: Forgetting proxy bypass rules (no_proxy, “Use system proxy,” etc.)

A bypass list can silently route your traffic around Burp. When in doubt, simplify: explicit manual proxy, minimal exceptions.

Personal note: I’ve lost more time to bypass lists than to actual bugs. Bypass lists are the friendly ghosts of networking.

Troubleshooting by evidence: logs and checks that end guesswork

When things don’t work, your job is to reduce ambiguity. You want to answer three questions—fast:

• Is Burp listening?
• Is Firefox actually using the proxy?
• Is HTTPS failing because of trust, or because traffic isn’t reaching Burp?

Burp-side: listener status, event log, and “am I receiving anything?”

• Confirm Proxy listener is running on the expected interface/port.
• Open Burp’s event log and look for obvious failures.
• If Proxy history stays empty during an HTTP test, treat it as a path problem, not a certificate problem.

Firefox-side: proxy exceptions, DNS-over-HTTPS, and cert errors that signal the real issue

• If HTTP doesn’t show up in Burp: proxy path/bypass is your focus.
• If HTTP shows up but HTTPS warns: certificate import/trust is your focus.
• If Burp shows CONNECT tunnels but pages fail: you’re close—trust or TLS negotiation is likely next.

UTM-side: networking mode sanity (NAT vs bridged) and why it changes reachability

If everything runs inside the VM, NAT vs bridged usually won’t matter for Burp ↔ Firefox. It matters when you try to intercept traffic from outside the VM (like macOS browsers or another device). If that’s your plan, you’ll need:

• A reachable IP for the VM
• A Burp listener bound to an interface that can accept those connections
• Firewall awareness (inside the VM and potentially on the host network)

If you want a clean explanation of how these modes change reachability (even though the UI differs across hypervisors), the core concepts are the same as NAT vs host-only vs bridged networking: you’re choosing what “reachable” means, then living with the consequences.

Personal note: the day I stopped “trying random settings” and started running one clean test at a time, my success rate jumped hard. Not because I got smarter—because I got calmer.

FAQ

Why does Burp Suite say “Browser Not Available” on Kali ARM64 but not on Intel?

Because the embedded browser launch path depends on your runtime and desktop environment. On ARM VMs, mismatched Java defaults, missing GUI libraries, or helper-process quirks show up more often—even when Burp’s proxy core is fine.

What’s the best way to install Burp on Kali ARM in 2025—installer or apt?

If you want predictability, use the official Burp release from PortSwigger. Package-managed builds can work, but they add extra variables (Java/runtime packaging differences) that make troubleshooting slower.

Which Java version should I use for Burp Suite on Kali ARM?

Use the Java runtime that aligns with your Burp build’s expectations. If you’re unsure, keep it simple: standardize on the runtime recommended by PortSwigger for your Burp version, and avoid mixing multiple Java defaults mid-session.

How do I set Firefox to proxy both HTTP and HTTPS through Burp?

In Firefox Network Settings, choose Manual proxy configuration, set the HTTP proxy to Burp’s listener, and enable the option to also use it for HTTPS. Then test with one HTTP page to prove the path.

Why does HTTPS fail even after I installed the Burp certificate?

The most common reason is that the certificate was imported into the wrong store, or the “trust websites” option wasn’t enabled. Mozilla Support documents where Firefox stores certificates and how to manage them—use that as your reference point.

Do I need to change Burp’s listener bind address (127.0.0.1 vs 0.0.0.0)?

If Firefox and Burp are on the same VM, 127.0.0.1 is usually perfect. If you’re proxying traffic from outside the VM, you may need Burp to listen on an interface reachable from that other device. Only widen the bind address when you understand who can connect.

Why does nothing show up in Burp when Firefox is “using the proxy”?

Start with an HTTP test page. If it still doesn’t show, check Firefox proxy exceptions, bypass lists, and whether your proxy host points to the correct machine in your topology.

Should I disable DNS-over-HTTPS in Firefox when using Burp?

Not forever—but during troubleshooting, simplifying the system helps. If you suspect DoH is confusing your evidence, disable it temporarily to confirm the proxy path and TLS trust cleanly.

What UTM network mode should I use for a Burp VM (NAT vs bridged)?

If Burp and Firefox run inside the same VM, either mode usually works. If you want other devices (or the host) to reach Burp inside the VM, bridged networking can make reachability simpler—but it increases exposure, so configure it deliberately.

Is it safer to use an external Firefox instead of Burp’s built-in browser?

For many lab workflows, yes—external Firefox reduces moving parts and makes debugging clearer. Burp’s built-in browser can be convenient, but it adds an extra launch chain that can break on ARM VM desktops.

Next step (one concrete action)

If you only do one thing in the next 15 minutes, do this in order—no improvisation:

1. Open Burp and confirm the Proxy listener is running.
2. Open Firefox inside Kali and set a manual proxy to Burp’s listener.
3. Load one HTTP page to confirm traffic appears in Burp Proxy history.
4. Download Burp’s CA via Burp’s built-in CA page and import it into Firefox Authorities.
5. Reload one HTTPS page and confirm it loads without warnings and appears in Proxy history.

One last personal note: when your tools misbehave, it’s easy to treat the setup like a moral failing. It isn’t. It’s a system. Systems respond to order. Give it order, and you get your evening back. And if you want your “lab self” to stay calm under pressure, small workflow upgrades like a solid Zsh setup for pentesters can quietly save more time than yet another reinstall.

Last reviewed: 2025-12.