VPN server for organizing telephone communications at a remote office based on a PBX Panasonic TDE100

Good time of day.
I propose another solution that I implemented three months ago and showed sufficient efficiency.
This article is intended to describe the application solution in the selected conditions. In addition, as such, I did not find a description of how to solve my problem in one place, therefore the solution is the result of searching for information in various sources. In short, who knows how useful?
So, we have:
Remote office in another city, the provider is local, there is no dedicated IP (assigned by the DHCP provider).
Mini - PBX Panasonic KX-TDE100, with included licenses for internal VOIP Phones (16 pieces) and SIP phones (16 pieces). Also in the PBX installed boards analog phones 3 * 16 and 16 incoming city lines.
Phone KX-NT321, located in a remote office.
Dlink DIR-300, with DD-WRT wired into it, at a remote office, to connect to my VPN server.
Picture to attract attention:


First there was the desire to implement a VPN server on the FreeBSD gateway by installing pptpd. However, as it turned out, in FreeBSD you need to patch the system to support mpd, which for some reason didn’t take off on a working system at all.
Ubuntu server was installed 13.10. Further, in order without describing your throwing, I will give the result of the adjustment:

sudo apt-get update && sudo apt-get upgrade sudo apt-get install ppp pptpd 

I will give the server network interfaces:

 ifconfig eth0 Link encap:Ethernet HWaddr inet addr:10.1.1.209 Bcast:10.1.1.255 Mask:255.255.255.0 eth1 Link encap:Ethernet HWaddr inet addr:10.90.90.9 Bcast:10.90.90.255 Mask:255.255.255.0 

eth1 is looking out, eth0 is local area network. Address Mini-PBX 10.1.1.250.
Pptp server configuration in files:

 cat pptpd-options name pptpd refuse-pap refuse-chap refuse-mschap require-mschap-v2 require-mppe ms-dns 8.8.8.8 nodefaultroute lock nobsdcomp 

I must say that at the end of the file there must be an EOF, otherwise the service hangs, loading 99% of the CPU time. EOF is a line break and emptiness.

 cat chap-secrets # Secrets for authentication using CHAP # client server secret IP addresses user1 pptpd mysecret 10.1.1.211 user2 pptpd mysecret 10.1.1.216 

The file contains rigidly specified IP addresses, but you can set the address assignment as an automaton by replacing the IP address with "*". By the way, ip-addresses in ignorance issued from his own network, but you could write anything.
I already got access to the server to Windows using a white IP address, but there was no access from the router. Through trial and error, the DD-WRT release was lowered to 14896 (Firmware: DD-WRT v24-sp2 (08/07/10) std). On higher versions, ppp did not cling.
Configuring DIR-300:
1. The Setup - advanced routing - Destination LAN NET 10.1.1.0 Netmask 255.255.255.0 Gateway 10.1.1.209 tab.
Operating mode - router.
2. Basic Setup - Wan Connection - Automatic DHCP tab (we get the address from the provider’s router)
3. Network Setup - LAN 192.168.2.1 netmask 255.255.255.0 gateway 192.168.2.1 DNS1 10.1.1.30 (Here is my DNS server in the local network of my office, in which the mini-PBX is listed). The DHCP server for the 192.168.2.xx subnet is configured to issue ip addresses, and the binding 192.168.2.2 to the MAC address of the VOIP phone is scored there.
4. Services - VPN - PPTP-Client is enabled, the ip address of my server is specified, the remote subnet is 10.1.1.0 netmask 255.255.255.0, and the initialization string is ppp

 mppe required,no40,no56,stateless 

5. Services - VPN - PPTP-Client: NAT is disabled, user2 and password are logged in (that is, when connecting, the router receives the ip-address 10.1.1.216.
')
The result was the following: the router hooked to the server, received an IP address, and successfully pinged 10.1.1.209 (that is, the server’s eth1 address). But it did not go further, but I need to get through to 10.1.1.250. We conclude that the problem is in setting up routing + some firewall rules.
After lengthy research, a start-up script has turned out (during the take-off of the interface), which I will give below. For his sake, this article was started:

 cd /etc/ppp/ip-up.d cat /etc/ppp/ip-up.d/pppup #!/bin/bash iptables -L -t nat iptables -F iptables -X #  VPN (47  1723) iptables -A INPUT -i eth1 -p tcp --dport 47 -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 47 -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 1723 -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 1723 -j ACCEPT #    iptables -A FORWARD -o eth0 -p tcp -j ACCEPT iptables -A FORWARD -o eth0 -p udp -j ACCEPT iptables -A FORWARD -o eth1 -p tcp -j ACCEPT iptables -A FORWARD -o eth1 -p udp -j ACCEPT iptables -A FORWARD -o ppp0 -p tcp -j ACCEPT iptables -A FORWARD -o ppp0 -p udp -j ACCEPT iptables -A FORWARD -o ppp1 -p tcp -j ACCEPT iptables -A FORWARD -o ppp1 -p udp -j ACCEPT iptables -A FORWARD -o ppp2 -p tcp -j ACCEPT iptables -A FORWARD -o ppp2 -p tcp -j ACCEPT iptables -A FORWARD -o ppp3 -p udp -j ACCEPT iptables -A FORWARD -o ppp3 -p tcp -j ACCEPT iptables -A FORWARD -o ppp4 -p udp -j ACCEPT iptables -A FORWARD -o ppp5 -p udp -j ACCEPT # VOIP iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags RST,SYN SYN -j TCPMSS --clamp-mss-to-pmtu #   /sbin/route del -net 192.168.0.0 netmask 255.255.255.0 /sbin/route del -net 192.168.2.0 netmask 255.255.255.0 /sbin/route del default gw 10.90.90.1 # . (  -,       10.1.1.209,    192.168.2.2). /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.1.1.212 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.1.1.216 /sbin/route add default gw 10.90.90.1 

As for the line “Resolving VOIP” in the launch script, I can say this: I found it in the output far beyond the first hundred search engines in one of the forums, marked “try, it will suddenly work.” Before its introduction to the config, any traffic went except voice from the PBX. A voice from a remote office came.
Thanks for attention. I would be glad if this solution can help to quickly take off the VPN between remote offices.