A different problem for us:
We need an egress IP for whitelisting.
But after adding an egress IP, all our DB drivers can’t connect to external DBs anymore.
Does anyone have a clue, why this happens?
Thanks
Tobi
Edit: Checked it, releasing the egress IP → everything working fine again.
@lolgans I checked FRA. It should be working fine. Can you please check again?
As to why it didn’t work on Oct 23, I’m assuming you allocated the IP during the API outage.
Hey @akshit-fly,
thx for the help. I did a quick test right now and now everything seems to work correctly.
Will test in depth the following days and get it in touch with u again, if sth. fails.
Thx vm
Tobi
After configuring the egress IP for my machine, it appears that it can no longer access the internet, including my external database, which was the main reason I needed a static outbound IP.
I confirmed this by SSH-ing into the machine and attempting to ping external internet addresses, but it didn’t work.
How can I maintain a static outbound IP address while still allowing the machine to connect to the internet?
Could you point me to the documentation that shows me how to setup a proxy for all outbound connectivity so I can route all calls to my Azure resources through a static egress IP?
@NickSutton there isn’t exactly “fly documentation” for that, although I do have an example app that lets you deploy smokescreen proxy with HA.
In case your Azure resources support it, I would prefer creating a tiny machine on Azure and attaching that to your fly private network with fly wg. Static outbound IPs were specifically made for accessing services that don’t support a wireguard based setup.
I have in the past used an nginx reverse proxy attached to the Wireguard network to access a database in my Azure tenancy, however I need a way now to access multiple resources in my Azure tenancy and I would prefer to just route traffic to them as with that setup I would have to hang services off a separate port. Any new services that needed accessing would require an update to the reverse proxy.
My idea was to whitelist a static egress IP from Fly in Azure when I created the resource.
As far as I know, there’s no way to modify the routing tables in the fly network. If that’s changed then I would use a VNA on the wireguard VPN.
We are facing public internet reachability issue (like others) when applying an egress ip.
We tried it on a Seattle and then a Sydney machine. Both lost internet reachability. They were able to connect again after releasing the egress static ip.
One solution to this is not to use a reverse proxy but a “forward” proxy, such as those using the SOCKS5 protocol. Even ssh can act as a SOCKS5 forwarding proxy with the -D option, if high concurrency isn’t required.
Your use case seems best addressed by a small Azure machine running a SOCKS5 proxy attached to your Fly private network via Wireguard.
@PeterCxy Thanks for the response. I think we have narrowed it down a bit.
It just seems to fail on ICMP calls to outside/public networks. I think this egress IP mapping is done via a proxy connection, which seems to work fine for http connections but does not work for ICMP.
Is that expected or should the ICMP calls work over these egress ips?