Is it possible to change / configure the IP address that host.internal.docker gets mapped to?

[muya]

Scenario:

One of the services that we're running as part of our stack, Ory oathkeeper, has defined an "allow-list" of IP address ranges to which it can make requests (see https://github.com/ory/x/blob/8f55c13831d0ff51ffdb8c9211d3a987c13bad2c/httpx/ssrf.go#L91).

Since Orbstack assigns host.internal.docker to 0.250.250.254, the oathkeeper service is unable to make an API call to any endpoint on my host when addressed via host.internal.docker.

If interested, this repo contains details on how to reproduce the issue: https://github.com/muya/oathkeeper-ip-restrictions-demo

Basically, the scenarios fail when using Orbstack, and pass when not using Orbstack.

[kdrag0n]

You can try host.orb.internal instead, which has IPv6. The IPv6 address falls under the allowlist.

[muya]

Hello @kdrag0n - thanks for your response.

Is there a particular config I need to enable the IPv6 assignment?

Steps I took:

• In Orbstack settings, I checked "Enable IPv6"
• Restarted Orbstack
• Nuked all the containers and set them up afresh
• Attempted to reproduce the issue.

From within the container, pinging host.orb.internal is still resolving to an IPv4 address:

ping host.orb.internal
PING host.orb.internal (0.250.250.254) 56(84) bytes of data.
64 bytes from host.orb.internal (0.250.250.254): icmp_seq=1 ttl=62 time=0.783 ms
64 bytes from host.orb.internal (0.250.250.254): icmp_seq=2 ttl=62 time=0.500 ms
^C
--- host.orb.internal ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.500/0.641/0.783/0.141 ms

[getlarge]

Hi @kdrag0n, I have the same question for the same situation. Is there something else to enable/disable in Orbstack settings?

[ren-diao-quikbot]

For anyone hitting this specifically with Ory (Hydra / Oathkeeper) — the SSRF guard in ory/x rejects the OrbStack host.docker.internal (0.250.250.254, in the reserved 0.0.0.0/8 block) whenever an Ory service has to call a server running on the macOS host (a token hook, a webhook, a forward-auth upstream, etc.), with prohibited IP address ... denied by: 0.0.0.0/8. As noted above, the host.orb.internal / IPv6 suggestion didn't help me either — it still resolved to the same blocked IPv4.

A deterministic workaround that needs no host-IP hardcoding: drop a tiny TCP relay (socat) onto the same Docker network and point Ory at it by service name. Ory validates the resolved IP of the target host, and a container's compose-network address is RFC1918 (192.168.x / 172.x), which passes the allowlist. socat itself has no SSRF guard, so it forwards happily to host.docker.internal:

services:
  host-relay:
    image: alpine/socat
    command: TCP-LISTEN:8080,fork,reuseaddr TCP:host.docker.internal:8080
    extra_hosts: ["host.docker.internal:host-gateway"]
    networks: [your-network]

Then set the Ory upstream to the relay's service name, e.g. Hydra OAUTH2_TOKEN_HOOK_URL=http://host-relay:8080/... (or the equivalent upstream URL for an Oathkeeper rule).

Why it works: Ory resolves host-relay → the container's RFC1918 IP → passes the SSRF check; socat then connects to host.docker.internal (0.250.250.254) → the host. It's machine-independent (no LAN-IP to hardcode), survives DHCP changes, and is committable to your compose file.

Verified under OrbStack on Ory Hydra v2.3.0 (client-credentials grant, oauth2.token_hook.url → a server on the host): the hook call succeeds through the relay where the direct host.docker.internal URL failed with the 0.0.0.0/8 SSRF rejection.

Would still love a first-party knob to map host.docker.internal to an RFC1918 address (or a reliably-resolving host.orb.internal IPv6) — the relay is a clean stopgap but a native option would save every Ory-on-OrbStack user this dance.