Many years ago, Fry's Electronics had a close-out on 2014 era mini-ITX AMD AM1 motherboards and CPUs (less than $50 for motherboard, CPU, heat sink and fan). I've been using them, with suitably small cases, as NAT / router / firewall / DNS machines, and even though there are just four older 2 GHz cores, with NetBSD and npf I'm able to run at full gigabit speeds just fine. I've set up around ten of these AMD systems a…
> Neither helps if the line that you're using drops mid-call, but there are ways to deal with that, if you have high speed available at a datacenter. For instance, I've set up routing of a small public subnet via tinc ( https://www.tinc-vpn.org ) over two routing machines, each with their own Internet connection, with CARP so that packets can go through either machine. This makes handing off from one to the other tra…
I'm running tinc on NetBSD.
Starting with how it works and physical setup, you have tinc running, attached to a tap interface, bridged to an ethernet interface. The ethernet interface is configured on your LAN to route (not NAT) for your local computer(s) / VoIP devices.
What's good about this is that a machine on your local network (seeable from the ethernet that's part of the bridge) can be on a 100% public address, if you want, or on a private IP range. When routing, as opposed to NAT, only the endpoints care about the existence / state of any connections, which is one of the reasons the Internet is so resilient (your intermediate hops can change without needing to renegotiate sessions).
This means that intermediate machines, including the ones running tinc, can be down for a minute - even restarted - and, if the machines are patient, the endpoint machines will just see a temporary pause.
So take two machines, each running tinc, each configured with CARP, sharing the gateway IP for the public subnet from the upstream machine. Your local machine running your video conferencing software (or, perhaps VoIP phone) communicates through the primary (active) CARP local machine. Suddenly, a shot rings out! And the primary CARP machine dies, and the maid screams, but before the scream the secondary CARP machine takes over the IP and is routing those video (or SIP) packets, so we can hear the maid scream.
There are ways to failover NAT, but they're complicated because the primary and the failover machines need to constantly share the NAT state table. Even if you're routing (not NATing) private IP subnets, so long as you're doing NAT upstream, it still works.
Does that make sense?