Asterisk behind NAT, Clients Connect VIA VPN + NAT

Have been reading a lot about Asterisk and in forums before thought to post a problem too on this :slight_smile:

Asterisk Server setup is little complicated. Hope, below mentioned describes the best.

Endpoints first connect to a VPN Server with IP ranges from (172.16.0.0/16), that VPN Server makes a NAT to connect to our internal servers like 192.168.15.8 (ranges from 192.168.15.0/24). Here whenever endpoint tries to connect to asterisk server (192.168.15.221), the communication flows via VPN Server ( 192.168.15.8), that means whenever i check connection made to Asterisk server ( all clients connect with same IP (of VPN Server - 192.168.15.8) but, with different port.) like

192.168.15.8:28279 ==>192.168.15.221
192.168.15.8:28273 ==> 192.168.15.221

Endpoints get connected to Asterisk server (without a problem). but the call doesn’t happen/flow nor even the ring.pjsip logger.txt (12.6 KB)

I have also attached pjsip logger. Hope, it is described well.

The traffic into Asterisk is coming from an IP address of “172.16.0.2”. Asterisk is attempting to send SIP responses there, which is done if rport is requested/enabled which it is, and this appears to be failing. The endpoint retransmits its message and we retransmit our response, over and over.

Thanks jcolp!

Traffic is coming from 172.16.XX.XX to 192.168.15.8 (NAT Server) ==> 192.168.15.XX (ASTERISK SERVER).
Server is trying to respond back to 172.16.0.2 (which needs to go back via 192.168.15.8 (NATed)). I guess it is NAT, which is creating problem. Is there a way we can ensure traffic goes back to NAT Server (192.168.15.8) and then to 172.16.0.2?

It doesn’t appear to be going through the NAT. The source IP address of the underlying packet is 172.16.0.2. If going through NAT then the NAT should rewrite that to be itself.

The source IP address on that is 192.168.15.8, so yes.

This isn’t something controlled in PJSIP or in Asterisk. The IP packet itself has the wrong source. The problem is outside of Asterisk.

Thanks jcolp again!

It was different sort of issue & had to resolve making some different networking changes. AST was good.!