Anycast IP as TCP source IP

I’d like to be able to create a TCP socket and bind it to the fly-global-services address, and then have outgoing TCP packets to use the Anycast IP as their source IP.

I realize this might not be easy or a good idea in all cases, since TCP is connection-based and routing a response to the Anycast IP could interfere with that, but in most cases, the response should get routed to the same app instance, no?

I don’t actually think this is possible when you’re anycasting from multiple places. When you send a packet out with an anycasted return address, it’s very likely the response will go to another region entirely.

Are you just trying to connect out from predictable IPs or is there some other reason to do this?

In this case, it would be okay to have only a single instance of the app, so this would not be a problem, right? But I understand that single instance apps are probably not exactly your target market…

They’re not! But if that’s what you’re after, we are working on a way to give instances known, permanent IPs. Assuming you want the same egress IPv4 after each deploy, we should have a way to do that soon.

In this case, a static IP isn’t quite enough, since the server I connect to via TCP will ping me back on UDP on the TCP connection’s source IP for a sort of verification. So what really matters is that I can send TCP packets from the same IP I receive UDP traffic on.

If there could be some way to request one such a direct TCP tunnel for each instance spawned, and a way to read the port from the environment, that would be perfect! :thinking:

1 Like

Oh I see!

One thing you might look at is the proxy protocol for your TCP server (assuming you control it). It’s a nice way of encoding your desired source/destination IPs and ports into a TCP connection.

We use proxy protocol to let VMs get source IPs, but it should work equally well for sending a “new” destination IP.

Unfortunately that’s not an option, as the server operator made it a hard requirement that he pings the TCP source address. This is to prevent spoofing, I understand, and it makes sense: Anyone could make the server ping a random IP by pretending to be a proxy and encoding the target’s address as sender.

Actually, having the same egress IP across deployments would be helpful, now that I think about it. It would enable me to put a hash of that static egress IP into a DNS TXT record as a way to prove “ownership”, which the third-party server could check for. This way it knows the IP a domain points to is controlled by the same entity contacting it from another IP.
So yeah, I think such a feature would be useful to me!

Got it! It’s going to be a while before we solve either of these, sadly. This isn’t a problem we anticipated. :slight_smile: