2

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)

  1. 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

thepossum
  • 21
  • 2
  • 1
    How does Asterisk *bind*? (check for `bind-address` in the configuration) – Eduardo Trápani Jun 18 '21 at 19:08
  • Asterisk is listening on ALL available interfaces:[root@pbx ~]# lsof -ni | grep sip asterisk 18106 asterisk 17u IPv4 156106016 0t0 UDP *:sip asterisk 18106 asterisk 18u IPv4 156106019 0t0 TCP *:sip (LISTEN) – thepossum Jun 18 '21 at 20:31
  • Yes, but how? Can you please provide the value(s) of `bind-address`? – Eduardo Trápani Jun 18 '21 at 20:32
  • presumably you mean the "default" entry in Settings -> Asterisk Sip Settings -> Chan SIP Settings, which reads 0.0.0.0 – thepossum Jun 18 '21 at 20:40
  • some refs to follow: https://www.freepbx.org/freepbx-migration-towards-pjsip/ . If your current FreePBX is using chan_sip it has to migrate to the pjsip driver to allow multiple bind addresses. You should probably state your FreePBX version and what SIP driver is in use. While the problem is a known problem with UDP (and improperly implemented applications), its resolution is all about configuring the application here. – A.B Jun 18 '21 at 23:11
  • I should definitively point out here, that in an otherwise identical system, it's WORKING -- the difference being ONLY that the eth1 interface is using an ip on a private subnet 10.x.x.x, with zero trouble. THAT system just doesn't have to deal with the "source routing". The problematic system is only different in that the udp responses are evidently not being routed correctly via the source routing – thepossum Jun 21 '21 at 15:21
  • listening on INADDR_ANY (alias 0.0.0.0) is not the same as listening separately on each interface's IP address. UDP behavior and routing differs there for a multi-homed system. This doesn't affect TCP on the same multi-homed system, only UDP. I have a ready answer to explain this difference in details, but not an answer that will both explain the difference *and* solve your problems. – A.B Jun 21 '21 at 15:27
  • I'll just leave this as comments: there are two ways to solve this, and it has to come from the application, not from the network stack. 1/ ISC method (bind/named, ntpd etC.): bind to every available IP address on the system 2/ unbound method (this is a caching DNS server) add code in the app to use the socket option IP_PKTINFO. – A.B Jun 21 '21 at 15:31
  • YES it's a very recent Freepbx version 14 running. YES the extension is using pjsip. And the pjsip's settings screen has been entirely unhelpful in grokking what changes if any might even potentially help – thepossum Jun 21 '21 at 20:15

0 Answers0