VoIP client behind a VPN with DD-WRT

We have two sites with local networks interconnected by VPN tunnel and we have a VoIP server at one of the sites. The server side based on a PC with Windows 2003 Server (also acting as VoIP and VPN server) installed. On the other side we have a DD-WRT as the VPN client.

As we do not have static public IP’s, when the connection is “refreshed” (or get’s reconnected) the VoIP client not registering with VoIP server via VPN anymore.

We’ve  search the Internet to find out the solution, and found many similar problems/situations, but very few were applicable to VoIP server be on the other side of the VPN tunnel (because they were always on the Internet).

And why the ATA (VoIP client) can not get registered when there is a connection dropped and restored? Well, there’s a routing table in the router tells you the origin of the data and what its destination. This table in the DD-WRT can be accessed if type root @ DD-WRT: ~ # grep 10.0.1.1 / proc / net / ip_conntrack in an SSH session (where 10.0.1.1 is the ip address you want to see the result for):

udp 17 src = 192.168.2.2 dst 3569 = 10.0.1.1 sport = 5062 dport = 5060 packets = 49 bytes = 23100 src = 10.0.1.1 dst = 192.168.2.2 sport = 5060 dport = 5062 packets = 33 bytes = 15090 [ASSURED] mark = 0 use = 8


udp 17 src = 192.168.2.2 dst 3590 = 10.0.1.1 sport = 5065 dport = 5060 packets = 121 bytes = 54934 [UNREPLIED] src = 10.0.1.1 dst = 192.168.1.2 sport = 5060 dport = 5065 packets = 0 bytes = 0 mark = 0 use = 2


In the lines above are a few things to consider: 3569 and 3590 is the time that this line is active on the router. So during this time there is no data traffic will be excluded from this line and a new table could be created if another connection is needed.

192.168.2.2 is the address of ATA is that the network client, behind the DD-WRT.  The FXS port of the router’s FXO port 5065 and 5062.

192.168.1.2 is the WAN address of DD-WRT.

If we observe the rule that the DD-WRT set to port 5062 we will  see that it is correct because the origin is the ATA (192.168.2.2) and target the VoIP server (10.0.1.1).

As for the port 5065 the rule is incorrect because the router is sent packets that should go to the VoIP server (10.0.1.1) to the Internet (WAN router – 192.168.1.2).

This error occurred because the router was restarted and the ATA was hooked. The ATA asked the very fast router “I need to register the VoIP server 10.0.1.1, do you know the route?” As the router DD-WRT had just “wake up” and had not yet started the VPN connection he replied “I don’t know, so he should be on the Internet, I’ll refer you over there”. And so the line is established. As I explained before, this line it will take 3590 / 2 to be deleted and even if the VPN connection is reestablished this rule will not be excluded. What reason for that? It’s a Keep-Alive.

The Keep-Alive is present in the ATA and the router is saying in the time interval programmed “Please do not delete the line that was created for my ports 5065 and 5062, because I need them.” In short, if Keep-Alive is set in 20 seconds, when the the time of 3590 and 3569 wounds in 3570 and 3549 respectively they will again return to orinal value and the line will never be deleted from the table.

How we can solve this?

The first and simplest is to use random ports on your ATA – each time a reconnection event appears it will use a different port (instead of 5062 and 5065 for example). This will solve the issue because it will create another row in the routing table.

The second way is to apply (in our example case we need a static port to be able to configure the IP-PBX) and add to a command in DD-WRT that cleans the table whenever the router is restarted and also whenever there is a reconnection of the VPN tunnel. See below:

The script is:


sleep 80
sh /proc/net/ip_conntrack_flush

#!/bin/sh
while [ 1 ]
do
if ! ping-c 1 10.0.1.1; then
/tmp/pptpd_client/vpn stop
/tmp/pptpd_client/vpn start
/proc/net/ip_conntrack_flush
fi
sleep 20
done


Explanation of script: First we are waiting for the router to bootup and start the services (80 seconds), then we clean the table with ip_conntrack_flush. If you do not use a VPN and the problem occurs with a VoIP server on the Internet you can stop here, the other lines are not necessary. The following commands verify that the VPN connection is active in a range of 20 continuous seconds and if not restart VPN client again and then again clean the table.

We hope it works for you as well! Original solution posted by Tobias Tromm, translated and posted by voip-sip.org with direct permission from Tobias.