Asterisk Not Receiving Call From VPN Address

Home » Asterisk Users » Asterisk Not Receiving Call From VPN Address
Asterisk Users 28 Comments

Hi,

We have a Kamailio and Asterisk cluster, both machines being on a real
103.x IP address and also on a 172.x OpenVPN address.

The problem is that when Kamailo receives a call from the VPN and forwards it to the Asterisk server on it’s 103.x address, Asterisk never sees the call.

If Kamailio receives a call from the VPN and forwards the call to the Asterisk server on it’s 172.x address then it works. However, if the call isn’t from the VPN then forwarding it to the 172.x address doesn’t work. So basically the problem is going between the real network and the VPN.

The question is, how can we make this work when calls are received on either network on the Kamailio server and are forwarded to Asterisk?

Using ngrep on the Asterisk server we see that it does receive the INVITE, but Asterisk’s logging shows no sign it at all. We guess it’s a Linux networking issue rather than Asterisk’s fault, but don’t know where to fix it. We do have net.ipv4.ip_forward = 1 on both the Kamailio and Asterisk servers.

Thanks in advance for any help.

The ngrep on the Asterisk server:

U 2014/01/17 13:15:15.599557 172.x.x.x:5060 -> 103.y.y.y:5060
INVITE sip:9067268@103.y.y.y:5060;transport=udp SIP/2.0. Record-Route: . Via: SIP/2.0/UDP 172.x.x.x;branch=z9hG4bK50c7.f49ceb73.0. Via: SIP/2.0/UDP 192.z.z.z:5062;rportP62;branch=z9hG4bK806710997. From: “9067271” ;tag8791249. To: . Call-ID: 1905625787@192.z.z.z.
…

172.x.x.x is the Kamailio server’s VPN address
103.y.y.y is the Asterisk server’s real address
192.z.z.z is the calling phone’s LAN address

28 thoughts on - Asterisk Not Receiving Call From VPN Address

  • Sounds like a routing problem opposed to an application issue. You’ll have to fire up tcpdump on Kamailio and see what happens to the packet. The look at the local routing tables to see where it is getting routed. If Asterisk is not receiving the patch, then Kamailio is not routing it properly.

    You’ll be able to see everything once you have a pcap of the call.

  • Hi Paul,

    The ngrep on the Asterisk server does show it being received. Have you any idea what would prevent it getting from the network stack to Asterisk on that machine?

  • Have you got a static route on asterisk or your default gateway showing how to get back to the 172. addresses i.e. pointing to the vpn box for 172 addresses?

    Cheers Duncan

  • Hi Duncan,

    The Asterisk machine also has a VPN IP address, so it has a route for 172.x addresses to go to tun0 VPN interface.

  • Make sure you do NOT have any *bindaddr options set in your sip.conf. If you do, you are telling Asterisk to not allow the OS to pick the source IP and hence the routing.

    The *bindaddr options are seldom useful.

    —–Original Message—

  • Well, you need to use tcpdump on each hop across your network. If are Asterisk is not getting anything, either it is not receiving anything
    (check transmit side) or the firewall is dropping it.

  • Hi Eric,

    Thanks for the suggestion. It was on bindaddr of 0.0.0.0, but we tried removing that too, and Asterisk still doesn’t see anything.

  • Hi Paul,

    Using ngrep/tcpdump shows the packet clearly going from the Kamailio server and arriving at the Asterisk server. This is why it’s a mystery that Asterisk doesn’t see the call coming in. We tried removing the firewall (so iptables -L shows no rules at all) but that didn’t help unfortunately.

  • Can you show a packet dump of the SIP invites arriving at the asterisk PBX , mostly just confirming the ip address that the server is receiving packets on

    root@zespri:~# tcpdump udp port 5060 -A -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    18:52:23.063862 IP 192.168.51.7.5060 > 27.111.14.65.5060: SIP, length: 534
    E`.2.L..@…..3..o.A……u.OPTIONS sip:sip.2talk.co.nz SIP/2.0
    Via: SIP/2.0/UDP 192.168.51.7:5060;branch=z9hG4bK45a08b58;rport Max-Forwards: 70
    From: “Unknown” ;tag=as32fe455a To:
    Contact:
    Call-ID: 10c0242d16529fff78572ef91ef47237@192.168.51.7:5060
    CSeq: 102 OPTIONS
    User-Agent: FPBX-2.10.1(10.6.1)
    Date: Tue, 21 Jan 2014 05:52:23 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
    Supported: replaces, timer Content-Length: 0

    18:52:23.084330 IP 27.111.14.65.5060 > 192.168.51.7.5060: SIP, length: 472
    E…….9….o.A..3…….r.SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.51.7:5060;branch=z9hG4bK45a08b58;received=192.168.51.7;rport=5060
    From: “Unknown” ;tag=as32fe455a To: ;tag=as7b633145
    Call-ID: 10c0242d16529fff78572ef91ef47237@192.168.51.7:5060
    CSeq: 102 OPTIONS
    Server: 2talk PBX
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
    Supported: replaces Accept: application/sdp Content-Length: 0

    Also the udp ports asterisk is listening on

    e.g netstat -udpl Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:4520 0.0.0.0:* 1413/asterisk
    udp 0 0 0.0.0.0:4569 0.0.0.0:* 1413/asterisk
    udp 0 0 0.0.0.0:5000 0.0.0.0:* 1413/asterisk
    udp 0 0 0.0.0.0:5060 0.0.0.0:* 1413/asterisk

  • Hi Duncan,

    Thank you for your reply. Here’s the netstat:

    [root]# netstat -udpln | grep asterisk udp 0 0 0.0.0.0:5000 0.0.0.0:*
    6672/asterisk udp 0 0 0.0.0.0:4520 0.0.0.0:*
    6672/asterisk udp 0 0 0.0.0.0:5060 0.0.0.0:*
    6672/asterisk udp 0 0 0.0.0.0:4569 0.0.0.0:*
    6672/asterisk

    Here’s the tcpdump (tcpdump udp port 5060 -A -n -nn -i tun0) from the Kamailio server:

    17:13:17.103771 IP 103.x.x.x.5060 > 172.y.y.y.5060: SIP, length: 1228
    E…….@.>/g.v………….INVITE sip:*1@172.y.y.y:5060;transport=udp SIP/2.0
    Record-Route:
    Via: SIP/2.0/UDP 103.x.x.x;branch=z9hG4bK584f.d0387c07.0
    Via: SIP/2.0/UDP 192.168.1.40:5060
    ;received 3.z.z.z;rportP60;branch=z9hG4bK274588850
    From: ;tag80695235
    To:
    Call-ID: 1898224288

    Here’s the tcpdump (tcpdump udp port 5060 -A -n -nn -i tun0) from the Asterisk server:

    17:13:17.093676 IP 103.x.x.x.5060 > 172.y.y.y.5060: SIP, length: 1228
    E…….?.?/g.v………….INVITE sip:*1@172.y.y.y:5060;transport=udp SIP/2.0
    Record-Route:
    Via: SIP/2.0/UDP 103.x.x.x;branch=z9hG4bK584f.d0387c07.0
    Via: SIP/2.0/UDP 192.168.1.40:5060
    ;received 3.z.z.z;rportP60;branch=z9hG4bK274588850
    From: ;tag80695235
    To:
    Call-ID: 1898224288

  • Have you checked your localnet=, deny=, permit=, contactdeny= &
    contactpermit= settings?

    My 2c worth.

  • Hi Larry,

    Thanks for the reply. We have all of those settings left out of our sip.conf, so this should allow everything, right?

  • Cool

    That looks like it is arriving at Asterisk – are you sure asterisk is not getting it? If you turn on sip debug in asterisk can you see the SIP packets? It maybe asterisk is ignoring them or replying to them but its going out an interface you hadn

  • Hi Duncan,

    We have “sip set debug on” and nothing is shown, even though tcpdump/ngrep on the same server does. It’s very strange.

    The output of “ip address list” is:

    [root]# ip address list
    1: lo: mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
    2: eth0: mtu 1500 qdisc mq state UP qlen
    1000
    link/ether 44:1e:a1:4e:2f:b8 brd ff:ff:ff:ff:ff:ff
    inet 103.y.y.19/24 brd 103.y.y.255 scope global eth0
    inet6 fe80::461e:a1ff:fe4e:2fb8/64 scope link
    valid_lft forever preferred_lft forever
    3: eth1: mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 44:1e:a1:4e:2f:ba brd ff:ff:ff:ff:ff:ff
    4: eth2: mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 44:1e:a1:4f:30:a4 brd ff:ff:ff:ff:ff:ff
    5: eth3: mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 44:1e:a1:4f:30:a6 brd ff:ff:ff:ff:ff:ff
    6: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534]
    inet 172.x.x.14 peer 172.x.x.13/32 scope global tun0

    The output of “netstat -rn” is:

    [root]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface
    172.x.x.10 172.x.x.13 255.255.255.255 UGH 0 0 0 tun0
    172.x.x.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
    172.x.x.1 172.x.x.13 255.255.255.255 UGH 0 0 0 tun0
    172.x.x.18 172.x.x.13 255.255.255.255 UGH 0 0 0 tun0
    192.168.234.0 172.x.x.13 255.255.255.0 UG 0 0 0 tun0
    192.168.235.0 172.x.x.13 255.255.255.0 UG 0 0 0 tun0
    103.y.y.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    169.z.z.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
    172.21.0.0 172.x.x.13 255.255.0.0 UG 0 0 0 tun0
    10.0.0.0 172.x.x.13 255.0.0.0 UG 0 0 0 tun0
    0.0.0.0 103.y.y.1 0.0.0.0 UG 0 0 0 eth0

  • David,

    It seems to me that Asterisk is not seeing/binding to your VPN
    interface. You need to debug that first. I would set en explicit bind statement in sip.conf to the VPN interface address and nothing else.
    Then start your asterisk and watch the log messages. It should confirm that it cannot bind to that address. If it does bind, then try your test again and asterisk should see the SIP packets coming in.

  • You might think Kamailio is transmitting it to Asterisk, however without looking at the actually routing tables on Kamailio you’ll never know if it actually made it to Asterisk. Again, we need a pcap trace on both Kamailio and Asterisk, plus what your routes look like
    (route -n), for a call. It will show us clearly what is happening.

    This all sounds like a routing issue, so your network admins should be able to help troubleshoot.

  • I finally re-read the complete thread. When are you starting the VPN
    on your Asterisk server, before or after Asterisk has started? If after, and you are binding to 0.0.0.0, it is likely Asterisk is not actually bound to your tun0 interface. So, for a test, explicitly have asterisk listen only on the tun0 interface, retry your call.

    Or setup your tunnel, then stop Asterisk and start it again, that should cause it to bind properly.

  • Hi Andres,

    Thanks for the idea. We did send bindaddr to the VPN address and restarted Asterisk, but unfortunately that didn’t solve the issue. Asterisk didn’t complain, but still the “sip set debug on” didn’t show the packets.

  • Hi Paul,

    Thanks, we did try restarting Asterisk after the VPN was up but that didn’t solve the issue either.

  • (Please don’t top-post.)

    Have you confirmed via ‘netstat’ (or some other system level toop) that Asterisk is actually listening to UDP port 5060 on the VPN IP address?

  • Hi Steve,

    When we have bindport = 172.x.x.14 then “netstat -udpln” shows the following. When bindport is 0.0.0.0 then netstat shows it listening on
    0.0.0.0 as you’d expect.

    udp 0 0 172.x.x.14:5060 0.0.0.0:*
    18114/asterisk

  • At this point in time, you’ll need to show us a .pcap on the Asterisk box, when you make a call to it via Kamailio.

  • Hi Paul,

    Thanks for the reply. What are you looking for in the PCAP, that isn’t in the tcpdump earlier in the thread? I just want to make sure we gather the information required.

  • Ok, that is progress though. At this point we know that the OS is receiving the packet and Asterisk is listening on that interface and port. I know you already removed the firewall so that would not be the issue. My next guess is Asterisk is looking at the packet and dropping it because it believes it is not meant for it (Kamalio config issue), so try a simple test to confirm this. Just configure a remote IP
    phone/softphone via that same VPN interface to simulate a remote SIP
    endpoint. If the SIP phone works fine but Kamalio does not, that will clearly tell you where the problem lies.

  • Hello,

    We tried Asterisk 1.8 and 1.6, but not yet Asterisk 11. We’ll keep it in mind.

    In the meantime we’ve decided to try a different network configuration instead, so the VPN network is separated from what Asterisk sees.

    Thanks for all the advice given.