Cannot get FreePBX to route with dual NICs

I have a FreePBX server that needs to have a second real-world interface added. As in, both eth0 and eth1 have routable ip addresses. Setting up the second address was relatively simple as per a quick google search: https://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System 1. edit /etc/iproute2/rt_tables and added an entry "200 second" 2. added routes for the table called "second": ip route add ip.subnet.on.eth1/27 dev eth1 src ip.address.on.eth1 table second ip route add default via router.ip.for.eth1 dev eth1 table second (where "ip.subnet.on.eth1" "ip.address.on.eth1" and "router.ip.for.eth1" are the addresses needed) 3. added rules to send traffic through the right interface via source-routing: ip rule add from ip.address.on.eth1/32 table second ip rule add to ip.address.on.eth1/32 table second Which gave me some partial success: I could now route to the server's second ip address, such that it would immediately respond to normal requests (ie. icmp, sshd, apache, etc). But it is utterly failing to work with the udp services needed for Asterisk. Any client can connect fine to the "normal" ip address on eth0. But trying to connect to the eth1's ip, the client just times out. I even tried setting the server to accept tcp for sip, which then allowed me to log in; but it was ultimately unsuccessful, as the rtp (voice) traffic is also udp. Now, similar setups DO work, such as when the second eth1 device doesn't need to be globally routable, ie. for an internal LAN. So if the pbx has one real-world ip on eth0, and a private ip on eth1, then it's only using a single unified routing table and everything just works. I can definitively confirm that there is NO firewall blocking traffic to/from the sip server. In fact I've even got an explicit set of entries allowing ALL tcp and udp traffic to my sip client's subnet, bypassing all the fail2ban and other shenanigans. PS. if I haven't made myself pedantically clear, the end-goal is to have the Freepbx/asterisk functioning on BOTH interfaces eth0 & eth1, which both have fully-routeable real-world ip addresses. As it currently stands, only eth0 is functional