Proxying Outbound SIP Trunk

Configure SIP Trunk on Asterisk

This Guide Assumes you already have a PBX set up with phones and just serves as a guide to configure the outbound trunk so your PBX can receive external calls.

• We used https://sip.us for our outbound trunk
• Configure NAT Settings in Asterisk SIP Settings
• Documentation from https://sip.us for Asterisk
  • Outbound route configuration
    https://support.sip.us/hc/en-us/articles/201914187-Outbound-Route-Configuration-Asterisk
  • SIP trunk configuration
    https://support.sip.us/hc/en-us/articles/201914177-SIP-Trunk-Configuration-Asterisk

---

NAT, SIP, and RTP

NAT (Network Address Translation) modifies the IP address and port information in packet headers as they pass through a router or firewall. SIP (Session Initiation Protocol) uses different ports for signaling (usually UDP port 5060) and media streams (RTP, typically on ports 10000-20000). This can create complications because NAT devices often don’t handle the dynamic nature of SIP traffic well.

NAT Pinhole

A NAT pinhole is a temporary opening in the NAT table that allows inbound traffic to reach a specific internal IP address and port. These pinholes are created when an internal device initiates a connection to an external device. However, SIP traffic can be problematic because:

1. Dynamic Ports: SIP uses dynamic ports for RTP streams, which means new pinholes need to be created for each call. If the NAT device doesn’t properly handle these dynamic ports, the media streams may not get through.
2. Timeouts: NAT pinholes can time out if there is no traffic for a certain period. SIP signaling might keep the pinhole open, but if the media stream is delayed, the pinhole might close, causing the call to drop.
3. Symmetric NAT: Some NAT devices use symmetric NAT, which creates a unique mapping for each connection. This can prevent the SIP responses from reaching the internal device because the external device’s response might not match the original mapping.

---

_{Direct documentation from cisco}

“So, what are the issues and concerns with NAT in VoIP networks? Well, recall that NAT that we have discussed so far (losely referred to as basic NAT) only translates the IP address in the IP packet header and re-calculates the checksum, of course, but VoIP signaling carry addresses embedded in the body of the signaling messages. In other words, at Layer 5″

Figure 5 illustrates the effect of leaving the embedded IP addresses un-translated. The call signaling completes successful, but the SIP proxy at the service provider fails trying to route media (RTP) packets to media address sent by the call agent!”

^{Source: https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/211269-NAT-in-VoIP.html}

---

Wireguard setup between Freepbx & Asterisk server to our Oracle cloud server

1. Install PiVPN on your cloud linux server
– https://www.pivpn.io/
– Do this to save time instead of writing the Wireguard config files manually

2. Use the CLI to add a client

3. Edit the /etc/wireguard/wg0.conf file (wg server configuration)

4. Edit the /etc/wireguard/clients/[clientname].conf file

5. Copy client config to the client & start (PBX & SIP Server)

• Paste the client conf file contents into the /etc/wireguard/wg0.conf file on the client (Wireguard is point to point so technically it is two servers connecting)
• Execute sudo wg-quick up wg0 command to start wireguard on the client

---

General IP notes to give you a better understanding of our network setup

---

IPTables rules to allow SIP and RTP traffic to traverse from Wireguard interface to the public network interface

^{You will need to set these rules for traffic to be forwarded through NAT between the Wireguard interface and the public interface on your oracle cloud server. Yes, we have to use nat rules to fix the problematic NAT setup we are trying to work around, due to the nature of our wacky topology using a VPN to proxy traffic into the cloud Server functioning as an internet gateway.}

sudo sysctl -w net.ipv4.ip_forward=1
^{This is not iptables; it is a kernel parameter, allows packet forwarding between interfaces}

sudo iptables -t nat -A POSTROUTING -s 10.78.218.0/24 -o ens3 -j MASQUERADE
^{modifies the NAT table to send packets originating on the vpn subnet out the ens3 interface (our public cloud interface)}

sudo iptables -t nat -A PREROUTING -p udp –dport 5060 -d 129.153.163.16 -j DNAT –to-destination 10.78.218.2:5060
^{changes the destination of SIP traffic from our public cloud IP to our backend freepbx server}

sudo iptables -t nat -A PREROUTING -p udp --dport 5060 -d 10.0.0.111 -j DNAT --to-destination 10.78.218.2:5060
Same as previous, oracle cloud uses NAT and this was our inside public interface address so I just wanted to make sure that if anything ends up with that destination IP (Which it shouldn't) it will still be directed to our backend server

sudo iptables -t nat -A PREROUTING -p udp –dport 10000:20000 -d 129.153.163.16 -j DNAT –to-destination 10.78.218.2
^{changes the destination of RTP traffic from our public cloud IP to our backend freepbx server}

sudo iptables -t nat -A PREROUTING -p udp –dport 10000:20000 -d 10.0.0.111 -j DNAT –to-destination 10.78.218.2
^{catches any RTP traffic on our local public cloud IP and changes the destination of SIP traffic from our public cloud IP to our backend freepbx server}

sudo iptables -A FORWARD -p udp -d 10.78.218.2 –dport 10000:20000 -j ACCEPT
^{makes sure RTP traffic to our freepbx server is accepted and forwarded through NAT}

sudo iptables -A FORWARD -p udp -d 10.78.218.2 –dport 5060 -j ACCEPT
^{makes sure SIP traffic to our freepbx server is accepted and forwarded through NAT}

Now you should be ready to make inbound and outbound calls!

---

Incoming call is accepted by our SIP server