Hi All

I have a bare-metal Asterisk VOIP instance on my internal class-B network running Centos 7 and Asterisk 13.22.0.

On the same bare-metal Linux box I'm running docker with Kyle Manna's openvpn container from

https://hub.docker.com/r/kylemanna/openvpn/

With the standard procedure followed to configure and set up (per the above link) I can connect to this docker-hosted OpenVPN instance (running in the docker instance on the bare-metal Centos / Asterisk box) from a remote location using the Windows OpenVPN client and then access RDP (for example) and HTTP/S and Asterisk AMI, etc. served out from the Asterisk box and other servers on the above Class B network.

So the docker-hosted OpenVPN instance works for HTTPS/S, AMI, rsync, etc. protocols. I can access the VPN from a remote location and work inside it as if I'm on the local class B the VPN exports (e. g. the whole point of a VPN.)

HOWEVER

I want to use a VOIP softphone (3CX) across the above OpenVPN docker-hosted VPN instance from my remote location and this is proving completely impossible.

Running a tcpdump on the real-metal Asterisk while I try to connect the softphone over the docker-hosted VPN on the Asterisk, reveals that the UDP traffic to / from Port 5060 through the VPN to the Asterisk - which also hosts the docker - only runs in ONE direction.

where

As you can see, the 3CX softphone instance on my remote desktop sends a UDP SIP REGISTER request through the VPN. This gets to the docker, and it passes it from its internal eth0 interface "inside" the container to the docker0 interface on the real-metal Linux / Asterisk server "outside" the container.

The asterisk responds with a

back to the 3CX instance, via the local container, through the VPN, back to my remote desktop.

-THIS- never gets through back through the container, through the VPN, and onto the remote desktop where the 3CX softphone instance is running and waiting for the SIP/2.0 401 Unauthorized.

As you can see, 3CX on my desktop never receives or sees the SIP/2.0 401 Unauthorized response from the Asterisk at the office emerging out on my remote desktop VPN-ed in to the office.

The further traffic proves this, the Asterisk only keeps receiving register requests through the VPN, from my desktop instance of 3CX at my home, and Asterisk replies to the local docker0 IP of the container, but those UDP packets it replies with never reach the remote 3CX instance on my desktop on the other side of the VPN.

3CX has a debug mode and you can clearly see in there it keeps trying to register for about half a minute, then gives up as it never gets a reply - because replies don't travel through the OpenVPN container back through the VPN to the IP that requested the SIP REGISTER, which is my desktop machine at home.

How can I get OpenVPN, running in a docker network like this, to allow bi-directional UDP traffic on port 5060, through the VPN?

I suspect it is some kind of docker specific issue, as the same setup works correctly if OpenVPN is installed "bare" (without being containerized) on the same Centos Linux / asterisk machine at the office.

IPTables on both the physical bare-metal Linux box (the Asterisk) and the docker container itself have both been completely turned off already, no luck. I even disabled SELinux on the Asterisk temporarily to see it that had an effect.

UDP on port 5060 still just goes in ONE direction: VPN'ed desktop IP -> VPN -> Asterisk, and -never- Asterisk -> VPN -> VPN'ed desktop IP

Where do I start to look?

Thanks!

Stefan

Frankly, rylan76, you're dropping people in very, very deep. We're volunteers and passers by for the most part and that is a complicated house of cards you have there. SIP is not a regular topic, and you've too many VPNs and Docker instances about for us to get our heads around it without serious study.

Lesson 1: You're probably good at that sort of thing, having set it up, but you're stumped. So it's TOO complicated to be maintained and is therefore an engineering failure.

Lesson 2: You have to simplify. Have you thought of writing a script to listen on whatever port you're not getting through on and make a fingerprint file it it receives a ping/whatever then you can run copies of that script in your complicated path start to finish, and see how far it gets . Then solve it yourself, because I haven't a clue about docker. I do, however have a clue about diagnostics

Just thought I'd reply back on this and report it as solved.

The problems were several, among them was using the wrong IP address on the remote end of the Open VPN connection in the softphone client, and then also missing some settings on the Asterisk PBX that is local to the Docker instance hosting the KyleManna OpenVPN docker instance.

To recap, I have an Asterisk server in a remote office through which I want to make calls via an Open VPN instance using 3CX softphone from my home laptop while coming into the Asterisk through the KyleManna docker VPN.

To this end, I set up a docker instance with the KyleManna OpenVPN docker image on the Asterisk at the office, and then configured and set up an Open VPN user using the available guides.

I then wanted to use the Windows OpenVPN client on my home laptop to VPN into the Asterisk at work in the office, and then make calls over the VPN via the 3CX softphone through the office Asterisk, from home.

(I skip the required firewall setups, port forwards, etc. required at both ends to do the above, creating OpenVPN users, connecting with the GUI client from Windows, etc. etc.)

Problem 1 was I could then NOT get the 3CX softphone on my laptop at home to register and go on-hook on the Asterisk at the office, while VPN-ed into the Asterisk.

The issue was I was using the Asterisk's local office intranet IP as the SIP server in the 3CX settings on my laptop at home with the VPN up. This was incorrect, I had to use the KyleManna OpenVPN docker instance's Asterisk-local IP address in the 3CX softphone after opening up the VPN and connecting.

The asterisk was at IP a.a.a.a and I could ping and telnet etc. this IP to talk to the Asterisk from my home laptop once the VPN was up. But traffic was only flowing in one direction in that case when 3CX tried to SIP register from my laptop at home through the VPN, see my original post.

The KyleManna docker's IP on the Asterisk was b.b.b.b, and as soon as I pointed my 3CX softphone on my home laptop to the b.b.b.b IP, (instead of a.a.a.a for the Asterisk itself as previous) my VPN-ed instance of the 3cx softphone could register on the office Asteisk and traffic was flowing in both directions.

But then, if I made a call, there was no audio. At all.

Problem 2 was I was missing some settings for the Asterisk PBX to make this all work. I needed to add in the [general] section of the /etc/asterisk/sip.conf file the following

Where

b = the docker's IP on the Asterisk
c = the OpenVPN instance (via the KyleManna Docker) internal tunnel IP address range used for the VPN tunnel inside the KyleManna docker.

Then, for the specific extension I was testing [1010], I needed to change the extension settings in Asterisk in sip.conf from

to

E. g. the docker IP of the KyleManna OpenVPN docker (the b IPV4 address) had to be expressly permitted in the Asterisk sip.conf for the extension involved, and the "nat=force_port,comedia" had to be added in the Asterisk sip.conf for the extension involved, to ensure NATing works correctly to allow bi-directional audio, from and to the Asterisk behind the docker-ized OpenVPN instance, and from and to the 3CX softphone instance running on my laptop's Windows instance at home, while the docker-ized VPN instance is running.

In the above IP address (d) is a range describing the local office LAN address range.

E. g. this is now working and I can, using the KyleManna docker, generate and distribute VPN certificates to my colleagues which they can use to VPN in and do general work but also use company SIP trunks in the office, on the office Asterisk, via the SIP / RTP capable VPN connection they can now form using 3cx SIP phones on their laptops / desktops at home.

I'm glad you sorted it. I knew about the issues that can arise between windows and linux vpn protocols.

You can only fault find on something if you segment it as you did. The fact that so much was in Docker and behind firewalls made this harder than it had to be, I'm sure. But security comes with it's own overhead.

1 members found this post helpful.