Private networking not working

Hi,

I can’t seem to get private networking working. I have 2 apps:
purple-wave-4639 (has exposed ports / is the recipient of private networking requests)
quiet-glade-3869 (is the sender of the private requests)

In my sender I have experimental private_network=true and can confirm:

/ # cat /etc/resolv.conf

nameserver	fdaa::3

And also:

/ # nslookup lax.purple-wave-4639.internal
Server:		fdaa::3
Address:	[fdaa::3]:53

Non-authoritative answer:
*** Can't find lax.purple-wave-4639.internal: No answer

Non-authoritative answer:
Name:	lax.purple-wave-4639.internal
Address: fdaa:0:1bbc:a7b:85:1c66:438a:2

However all my requests to [fdaa:0:1bbc:a7b:85:1c66:438a:2] fail, on both the internal and public ports defined by the application. Hitting the application on the public ipv4 address and ports does return a response so the app is functional.

Am I just configuring something wrong here?

1 Like

My understanding is that to be reachable on the private network your app needs to bind to the private IP.

A simple example would be:

python -m http.server 8000 --bind $(grep fly-local-6pn /etc/hosts | awk ‘{print $1}’)

I believe that your app will need to bind to 0.0.0.0 and fly-local-6pn if you want the same port to be publicly and privately accessible.

1 Like

You can drop the bash incantation if you bind to _local_ip.internal

This is correct! Depending on the app stack, you can either bind to something like :: to listen on all IPv4 and IPv6 addresses, or bind specifically to the 6pn address.

Binding to either _local_ip.internal or fly-local-6pn will also work for some runtimes. It’s wildly inconsistent. You can test the latter by adding an entry to your local/etc/hosts and running your app locally.

2 Likes

Makes perfect sense - binding to [::] fixed it. Thanks all :slight_smile:

3 Likes