egress IP - not reflecting even after using the command

1

I have a js app deployed on fly which is calling the external service icanhazip (every 90 seconds) to know it’s egress IP.

say current IP as reported by icanhazip is A

❯ FLY_API_TOKEN=$FLY_IITKGP_TOKEN fly machine egress-ip allocate 7811ee1c425118

? Looks like you're allocating a static egress (outgoing) IP. This is an advanced feature, and is not needed by most apps.

Are you sure this is what you want? Yes

Allocated egress IPs for machine 7811ee1c425118:
IPv4: ...... 
IPv6: ....

let’s call the allocated egress IP as B

This was allocated to the machine. My app still calls the icanhazip and prints A.

I think it should print B.

2

when I updated the code,

all my egress calls are failing.
I verified this using fly ssh console to see if I can curl icanhazip.com.

This is the response

7811ee1c425118:/app# curl -vvv icanhazip.com
15:10:18.438713 [0-x] == Info: [READ] client_reset, clear readers
15:10:18.440340 [0-0] == Info: Host icanhazip.com:80 was resolved.
15:10:18.441026 [0-0] == Info: IPv6: 2606:4700::6810:b9f1, 2606:4700::6810:b8f1
15:10:18.441761 [0-0] == Info: IPv4: 104.16.184.241, 104.16.185.241
15:10:18.442385 [0-0] == Info: [SETUP] added
15:10:18.442910 [0-0] == Info:   Trying [2606:4700::6810:b9f1]:80...
15:10:18.644050 [0-0] == Info:   Trying 104.16.184.241:80...

and it hangs at the last line…

in short, after fly m egress-ip allocate <machine-id> the outbound calls from the app don’t work anymore.

3

app github repo

4

Hi… Unfortunately, there have been several recent reports of this feature failing—gradually congregating over in @ben_h’s subthread, :cricket: :cricket::

https://community.fly.io/t/static-egress-ips-for-machines/22004/37

It might help to post your FLY_REGION and the output of traceroute icanhazip.com there.

(I get 5 lines for the latter, from an ewr machine with a default egress IP.)

5 
> FLY_API_TOKEN=$FLY_IITKGP_TOKEN  fly  ssh console

Connecting to fdaa:2:5161:a7b:1d7:f6fb:4b6b:2... complete
7811ee1c425118:/app# traceroute icanhazip.com
traceroute to icanhazip.com (2606:4700::6810:b9f1), 30 hops max, 72 byte packets
 1  2605:4c40:95:c0eb:0:f6fb:4b6b:0 (2605:4c40:95:c0eb:0:f6fb:4b6b:0)  1.752 ms  0.672 ms  0.627 ms
 2  *  *  *
 3  *  *

7811ee1c425118:/app# echo $FLY_REGION
hkg
1 Like
6

Hi @mayailurus,

Just wondering if there’s any sense of the timeline for a fix here — are we talking days, weeks, or longer? We’re trying to decide whether to stick with Fly for static egress IPs or look at other options in the short term.

Any insight would be super helpful. Thanks!

7

Hm… Sorry to see that this feature is still glitching for people… I don’t work at Fly.io myself, but, personally, I’d be inclined to go with other options for now, :umbrella:.

(It’s too bad, because the static egress IP side really is pretty promising, overall…)

1 Like
8

Tagging you @akshit-fly

9

:wave: Outbound requests from your hkg Machines should be working better now. Let us know if you’re still having any trouble.

We did find a bug that caused the problem in this case. The immediate issue you reported should be mitigated, and a more lasting, preventative fix will be deployed soon.

Thanks for bringing this to our attention.

2 Likes
10

Thank you so much. This is resolved for me now!

11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.