Is it possible to route outbound traffic from a droplet through its floating IP. I.e., make http requests from the droplet that appear to originate from the floating IP?
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
The short answer is yes. The longer answer is that it depends on the software you are using to make the request. It needs to expose some way of binding to a particular interface. If it does, you’ll need to find what we call the “anchor IP” and use it. The easiest way to find the anchor IP is to inspect your Droplet’s metadata. From the Droplet, run:
- curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
In my case, it returns 10.10.0.8 If you wanted to make your request with curl you could then use:
- curl --interface 10.10.0.8 https://example.com
Or with wget you would use:
- wget --bind-address=10.10.0.8 https://example.com
In both cases, example.com would now see the request as coming from my Floating IP not my Droplet’s IP address.
Check out this tutorial for more info on Floating IPs: How To Use Floating IPs on DigitalOcean In particular, see the section on “Droplet Anchor IPs.”
The following worked for me on ubuntu:
Find the IPv4 gateway anchor:
curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/gateway | xargs route add default gw
If you’re concerned about copy / pasting random things (and you should be); the Floating IP gateway documentation can be found here:
https://developers.digitalocean.com/documentation/metadata/#interface-anchor_ipv4-gateway
This worked for me too (Ubuntu 18) but the change does not persist across reboots. I created a systemd unit file to run it on startup.
Step 1. Run this command to get the gateway for the floating IP
curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
Step 2. Run this command to make all outgoing connections appear to come from your floating IP, where $gatewayip$ is the ip obtained from the previous command:
route add default gw $gatewayip$
Someone could make a script to automate that in one shot.
I tried this but this killed all network activity to and from the droplet.
I then ran
route add default gw NON-FLOATING IP
Whilst this fixed networking again I then realised the IP I just added was still listed and the non-floating IP was listed twice so I ran this 3 times to remove all entries:
route del default gw NON-FLOATING IP/FLOATING IP
Then added it again with:
route add default gw NON-FLOTING IP
Now I am back to where I started though and cannot get Ubuntu to use the floating IP for SMTP as attempting to bind to that address causes AMAVIS to block the outgoing messages.
That command returns the anchor ip address not the gateway. You need to run the following to get the gateway:
curl -s 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/gateway
Thanks I thought there might have been something wrong with the instructions above. Your command worked and I was also able to get the netmask that way too.
However whatever I do, outbound connections from my Ubuntu server always show the droplet IP and not the floating IP. If I can’t direct outbound traffic through the floating IP then it seems to be of little value for redundancy/resilience/maintenance as whilst I can set incoming connections to the floating IP, as outbound connections have a different source IP things like mail servers don’t work as get blacklisted.
I set the DNS of about 30 domains to the floating IP with the idea I could quickly swap these if I needed to switch to a backup server (without doing 1 by 1 from the DO control panel) but maybe I am misunderstanding what floating IPs are for?
On a droplet you should have 2 IP addresses. The instance IP and the anchor IP. The default gateway is set to the gateway on the instance IP network.
I was able to follow these steps to direct outbound traffic through the floating IP:
Get the Anchor IP gateway:
curl -s 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/gateway
Set the default gateway to the Anchor IP gateway:
route add default gw <ANCHOR IP GATEWAY>
Remove the instance IP gateway:
route del default gw <INSTANCE IP GATEWAY>
Check outbound IP address (this should return your Floating IP):
curl icanhazip.com
Thanks for the reply Eric but I still can’t get it to report the IP as anything other than the instance IP. Posting IPs as set up a test droplet and have deleted it again.
Instance IP: 159.65.84.202
Floating IP: 139.59.203.32
Running the check currently shows the 159 address as expected:
curl -4 icanhazip.com = 159.65.84.202
I then run the command to get the gateway IP:
curl -s 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/gateway = 10.16.0.1
I then add a new default gateway using this address:
sudo route add default gw 10.16.0.1
I then try to remove the other existing default gateway and get an error
sudo route del default gw 159.65.80.0 = SIOCDELRT: No such process
This is what route displays (after the successful add command):
root@rwshostingtest:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 0 0 0 ens3
default _gateway 0.0.0.0 UG 0 0 0 ens3
10.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens3
10.16.0.0 _gateway 255.255.0.0 UG 0 0 0 ens3
10.131.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens4
10.131.0.0 10.131.0.1 255.255.0.0 UG 0 0 0 ens4
159.65.80.0 0.0.0.0 255.255.240.0 U 0 0 0 ens3
The curl command still returns the other IP:
curl -4 icanhazip.com = 159.65.84.202
So still can’t get this to work
This command was a success:
ip route del 159.65.80.0/20
But then ip route still lists the instance IP.
Ok I’ve worked it out at last and got it working.
First you need to get the gateway IP
curl -s 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/gateway
Then add this as a new default gateway:
route add default gw <ANCHOR IP GATEWAY>
Then run route -n to see the networks:
route -n
This displays the routing table:
0.0.0.0 10.16.0.1 0.0.0.0 UG 0 0 0 ens3 0.0.0.0 159.65.80.1 0.0.0.0 UG 0 0 0 ens3 10.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens3 10.16.0.0 10.16.0.1 255.255.0.0 UG 0 0 0 ens3 10.131.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ens4 10.131.0.0 10.131.0.1 255.255.0.0 UG 0 0 0 ens4
From this I can then work out the command I need to run to delete this second line:
route del -net 0.0.0.0 gw 159.65.80.1 netmask 0.0.0.0 dev ens3
Now the curl command shows the floating IP:
root@rwshostingtest:~# curl -4 icanhazip.com 139.59.203.32
I think this demonstrates working with floating IPs could do to be a bit easier on DO (so this was handled in the control panel) or at least documented how to switch. Also if I was to need to quickly change the IP for failover I think I would still have to follow these steps or something similar.
Your posted reply below does not work for me unfortunately, after I run the commands the droplet cannot connect to the public internet. I’m on Ubuntu 18.04, do you know what has changed since then and how I can send outbound traffic through the floating IP?
@apexinvesting
Hi, running route add default gw ip-number kills the current ssh connection and afterwards, it seems I am unable to log in again.
You will want to use the floating IP to login to SSH after you run the default gw command.
here you go, This is the answer you are looking for: https://blog.programster.org/openvpn-digitalocean-ip-alias
@ComputerUser I was on 18.10 I believe when I was trying this. However as I could not get system services to use the floating IP I gave up on it and switched back to the main IP.
It would have saved so much time not having to update DNS on a load of domains and just switch the floating IP between servers but when your email is being received on the floating IP but sent out on the main IP this does not work and leads to the mail server being blacklisted. DO did agree it was too difficult to work with floating IPs and recommended giving up on them until they worked better (e.g. so the server saw it as the primary IP ).
Floating IPs could be a great feature for disaster recovery features (i.e. switch the IP from one server to another without having to edit a load of DNS entries and wait for the cache to update) but it seems they are not there yet.