My VPS provider is running a promotion where I can get up to 5 additional public IPv4 addresses for a one-time cost of $25 each. I have always only used a single public IP address per VPS. Would there be any advantage of having additional public IP addresses?
I know some people do not consider a VPS self-hosting, but this is the most relevant community I could think of and the question is also applicable for homelabs as well.
You can route traffic in different ways, for a high traffic endpoint hook an IP straight into nginx, while regular to via virtual opnSense router, that adds overhead but more flexible routing. Got PVE with virtual networking inside.
It helps to download content (like YouTube videos for PeerTube instances) when you’re rate limited
To go on top of the reverse DNS/mail comments, it can also be useful for running a service like codeburg pages, or some other program that handles its own virtual hosting and TLS, without interfering with your more traditional services.
You got the basic idea from other posters, but there’s also a lot of weird crap in there as well.
Basically you only need multiple IPs when dealing with services that only really operate on “well known ports”. DNS and SMTP being the usual culprits. For most home users there this is no big deal - even if you wanted to host those services it’s unlikely that you would need more than one ip to do so. HTTP solved this in '97 with HTTP/1.1 which allowed for host headers, which let’s a single server host multiple sites.
This isn’t something new that nginx solved. 😂
It helps with spam campaigns.
Having two could be useful - allows you to separate anything that virtual you wants to host from anything real life you wants to host.
(Without having two domains pointing at the same IP)
You can run two different services on same port, but different ip …
Not really that important anymore, with caddy or nginx it’s easy to get around that for http or https …
Kids seem to think host name based routing is "new’… It worked fine in the 2000s with Apache.
It is a lot simpler nowadays. Download Caddy, put a 2 line config and you are good to go.
I guess that’s “a lot simpler” than 6 lines of config?
by factor of 3 obviously…
For http(s), yes. Other services that don’t support host routing, which is most of them, no.
Most things people self host are either torrent clients, HTTP(s) or are game servers. The first one can pick a port arbitrarily. The second can do host routing. The third - some of them support SRV records so you can direct the client to an arbitrary port. It’s becoming less common to need multiple public IPv4 addresses.
Yes, I have always used a reverse proxy which seems to eliminate the need for multiple IP addresses. It seems like having multiple IP addresses just creates additional cost and complexity, but I have seen many VPS providers offer multiple IP addresses, so I was curious if there was a use case that I was not aware of.
It’s mostly a relic from an older time, it can be useful for more traditional services and situations that struggle with sharing public IPs. In theory, things like multiple IP addresses (and IPv6’s near unlimited addresses) could be used to make things simpler – you don’t need reverse proxies and NAT and port forwarding (all of which were once viewed as excessive complexity if not outright ugly hacks instead of the virtual necessity they are today).
Each service would have its own dedicated public IP, you’d connect them up with IP routing the way the kernel gods intended, and everything would be straightforward, clear, and happy. If such a quantity of IPs were freely available, this would indeed be a simpler life in many ways. And yet it’s such a distant fantasy now that it’s understandable (though a little funny) to hear you describe it as “additional complexity” when, depending on how you look at it, the opposite is true…
From a modern perspective, you’re absolutely right. The tables have really been turned, we have taken the limitation of IP addresses in stride, we have built elaborate systems of tools and layers of abstraction that not only turn these IP-shortage lemons into lemonade, the way we’ve virtualized the connections through featureful and easily-configurable software layers like private IP ranges, IP masquerading, proxies and tunnels can be used to achieve immense flexibility and reliable security. Most software now natively supports handling multiple services on a single IP or even a single port, and in some cases it requires it. This was not always the case.
It’s sort of like the divide between hardware RAID and software RAID. Once upon a time, software RAID was slow, messy, confusing, unreliable, and distinctly inferior to “true” hardware RAID, which was plug-and-play with powerful configuration options. Nobody would willingly use software RAID if they had any other choice, the best RAID cards were sold for thousands of dollars and motherboards advertised how much hardware RAID they had built-in. But over time, as CPUs and software became faster and more powerful, the tide changed, and people started to realize that actually, hardware RAID was the one that left you tied to an expensive proprietary controller that could fail or become obsolete and leave your array a difficult to migrate or recover mess, whereas software RAID was reliable, predictable, upgradable, supporting a wide variety of disk types and layouts while still performing solidly and was generally far nicer to work with. It became the more common configuration, and found its way into almost every OS. You can now set up software RAID simply by clicking an option in a menu, even in Windows, and it basically works flawlessly without any additional thought.
Times change, we adapt to the technologies that are most common and that work the best in the situations we’re using them in, and we make them better until they’re not just a last resort anymore, but become a first choice, while the old way becomes a confusing anachronism. That’s what multiple public IPs have become nowadays, for most purposes.
By “modern” do you mean “the late 90s”? HTTP 1.1 was adopted in '97 and allowed for the host header. NAT and port forwarding have been around since '94 - 2000ish.
Many services worked on any ports at the time as well. SMTP and DNS are probably the only ones that were (and remain) difficult to run on non-standard ports.
The main thing is log separation
It’s a lot easier to figure out why your service is broken if it’s the only service on the IP versus there being 10 services on the same IP all dumping into the same log. Lets me grep a lot easier
If your vps is a firewall, you could use it as an exit point for different private networks: ip1 to mask the traffic for a guest subnet that you don’t trust and if the ip gets blacklisted there are no issues for lan traffic behind ip2 while ip3 is reserved for server traffic with specific rulesets on supplier’s systems for updates/backup/whatnot. Should you have more than one mail server because of reasons, if one is blacklisted the other could remain clean (in this situation you usually put them on different subnets but whatever).
You can ping yourself
If you keep pinging yourself you’ll go blind unless you enable spanning tree protocol
Ping me yourself, you coward!
Ping
Not really useful though
There are cases where forward and reverse DNS need to match, and you may not want to have any association between two domains. SMTP is something that comes to mind. If your HELO/EHLO domain doesn’t match up, there are many servers that just won’t deliver your mail. I host my own email, and I work with very technical people. I don’t want “fun-domain.com” and “domain-on-my-resume.com” resolving to the same IP address. But I can host them on the same server.
There’s still some software out there that does not support SNI.
While your post body focuses on VPS, your question doesn’t, so I’ll also mention self hosting your own VMs. You can do a lot with reverse proxies and funky port based traffic routers, but sometimes just giving the VM it’s own IP is way simpler. Especially if you don’t mind hosting the VM, but aren’t interested in managing the service. I host a VM for a MUD I used to play. I don’t run the MUD, I don’t want to. I want them to be able to do stuff on their website without me having to edit a reverse proxy config, or without having to give them access to the host server.
It can also be used to increase the number of connections you can have to a single interface.
Perhaps you’re hosting your own VPN and you want traffic to come out an entirely different interface than the one your other services are on, for segregation reasons.
A secondary IP can also allow for a bit of service redundancy. Probably not the most relevant thing in self-hosting land, but the ability to move an IP between two different VPSs (assuming they’re on different hypervisors anyway) is pretty handy.
Exactly. Reverse DNS lookup matters in some situations.
Few of them for most use cases, especially a VPS. My server have a couple of IPs each mapping to a different VM, they can all claim 22/80/443 as you’d expect, but that’s just basically the same as having a bunch of VPSes anyway.
It’s useful for some other uses like, I might want to dedicate an IP for VPN exit that doesn’t expose any services.
Another use is sometimes you just want two things to stay entirely separate, even if on a technical level it could work with a reverse proxy. It can eliminate some class of exploits like request smuggling.
One use case I’ve had for a customer is they have a system that can only do TLSv1.0, which is wildly obsolete and exploitable. So that particular API endpoint was served from a secondary IP, that way I can continue to enforce TLSv1.2+ on the primary IP. It’s possible with some reverse proxy magic with HAproxy, but I could also just make a new server block in the existing NGINX bound to that IP and call it a day.
You can also have different SSL settings per virtual host with nginx. No need to use different IPs for that.
I don’t remember the exact details but it didn’t work right. That was arguably a couple years ago on a server distro approaching EOL, may have been long fixed. It involved Android 4.4.
It depends on the use-case. If this VPS doesn’t have layer7 routing out in front, you have a service that needs to respond from an A/CNAME hostname in combination with an SRV lookup, you have service that uses bidirectional TLS 1.2…etc.
There’s all kinds of reasons you may need multiple static IPs for an instance. If youre just using vhosts for HTTP capable services, don’t worry about it though.
What do you use your server for? Folks could provide answers relevant to your use case if you mention that. Just a thought.
I just run some simple services, such as Audiobookshelf or Wallabag, behind a reverse proxy. After reading the other comments, it does not look like there would be any benefit for my use case.
The one use case is running STUN/TURN server for NAT hole punching, that requires two separate servers, or one server with two IP addresses. You will only need that to run masterserver for games that support hole punching, or to run VoIP telephony / teleconference server.
Another use case is reliability, when your server is connected to several network providers, it will keep working if one of them has an outage, and will naturally have a different IP address for each network link. But your VPS does not have several network links, otherwise they would advertize that in bold red letters.
Why can’t you run the STUN/TURN server on the same IP?
Because you won’t determine the type of NAT during hole punching. This requires the client sending two UDP packets to two different IP addresses, then comparing their source addresses on the server.
Normally yes, you can just assume that two clients you are trying to connect both have port restricted cone NAT, and run the hole punching algorithm, and if the connection fails after ten seconds, show message to the users ‘Error 418: your router is a teapot’.
Two different rDNS names, for stuff that uses it. For example if you want to run mail and an IRC bouncer under different domain names.
You could run multiple mail servers. Or download from Sharehosters in parallel. Or download more Youtube videos before the rate limit stops you. Or use virtualization or containers to launch some more virtualized servers.
