OK - let’s start at the top.
That’s a laudable setup. There are a few problems with it, though. In fact, your ability to do what you need to do (as described below) starts to fall apart here pretty quickly.
I don’t need to imagine it. Every installation I run has this feature. Almost all of my installations use multiple gateways through my border router (which is a NetBSD IPF Firewall).
Yes it would. The problem is that you won’t. No matter how you want to do it, you will need to reconfigure the server’s external address. Also, calls “in flight” are going to fail.
The problem is that your NAT can’t handle dual interfaces. I understand that you have a 1-to-1 NAT for both of your external IP addresses, but Asterisk only has one. You need to reset the external address in the server and restart Asterisk for you to be able to change the “external” address that the system is using.
You might be thinking at this point that it will just switch, and incoming traffic will actually probably fail over, but you’re immediately going to run into one-way audio problems because the SIP and RTP protocols embed the designated external address inside their packets. If your identified external address is 22.214.171.124 (for example) and you suddenly switch all of your SIP and RTP traffic to go through 126.96.36.199, the packets will still say ‘188.8.131.52’ until you change it.
Now having said all of that - it is possible to externally change the external interface address and switch address by restarting Asterisk. You will need to write some software to make it happen and to make it respond the way you want it to. It won’t be “manual”, but it’s not guaranteed to go completely smoothly.
Now, all of that is external to the phone server. Having two interfaces to the local network isn’t going to improve your reliability. In fact, it might mess your reliability up. The next problem is your pfSense router/firewall.
Let me explain. Your internal address for your firewall is 192.168.1.1. The other internal address is 192.168.2.1. Each of these is mapped “1-to-1” to the external addresses ‘184.108.40.206’ and ‘220.127.116.11’. To get there, they traverse the same local network (192.168.0.1/22) and are sent out via the default port from the pfSense.
You can have all the addresses you want, but ultimately, you end up with a mess. Your system is going to rely on whatever default route is in place - assuming you’ve configured pfSense to fail over (implementing OSPF or BGP would be my guess), the traffic is going to go out to whatever address is closest.
This is confusing stuff, but it’s really nuts-and-bolts of routing.
Here’s an example. You receive a call from your ITSP. It is routed to 192.168.1.1. via 18.104.22.168 and is processed and forwarded from pfSense to get the traffic there. Life’s good. This, so far, is a standard Asterisk setup.
You, however, have added a wrinkle. Your ISP at 22.214.171.124 fails (line fade, power, whatever). Your traffic is suddenly coming in on 126.96.36.199 to 192.168.2.1. The server is still set up to tell the other end that the address at this end is your old external address (188.8.131.52). even though the traffic is coming in for 184.108.40.206. The traffic is now open jawed through a dead connection. The only way to get this connection to work is to change the external address for the SIP connections, which will fail as soon as your original ISP comes back on line.
So, where you looking for redundancy, you’ve just caused two outages for every outage. This is the opposite of where you wanted to end up.
So now, a suggestion. Instead of the 1-to-1 mapping, set up your phone system so that it has a single “external” address - pick one, it doesn’t matter.
So now, you have two potential incoming routes (redundancy achieved for this leg). Both of these addresses get routed to your single IP address in the local network. The routing tables for the server are simplified. You’re still going to have some work to do in the pfSense switch, but that’s external to this phones.
Use a job that monitors the incoming IP address, and when the primary fails, you change the “external” address of the server to the other external address and restart Asterisk. All of your calls drop at this point, but they were probably gone anyway, since the link they were coming in on went down. Once the server restarts, all of the phones will reconnect and your incoming calls will come in on the second external address and be processed through that address (since the external address is set correctly).
The reliability problem is still there, though. Every time you switch from one ISP to the other, you end up having to change the external address in the server and restarting Asterisk.
Even if you DID have to do it manually, it wouldn’t take more than a few seconds. Letting it happen automatically, could reduce your reliability to nearly zero. The constant switching back and forth between two networks is going to kill all of your calls and force a restart of the server. This is basically the opposite of where you wanted to end up.
Now, there may actually be a device out there that will let you do this, but it won’t be Asterisk. I’m going to invite @dicko into the conversation, cause knows a lot more about the call routing stuff than I do. He might be able to get you to where you actually want to end up.