SIP UDP traffic only flowing in one direction in a docker network with dockerized OpenVPN instance
by rylan76 from LinuxQuestions.org on (#5D94J)
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.
Code: tcpdump -i docker0 -c 20 -nn port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on docker0, link-type EN10MB (Ethernet), capture size262144 bytes
14:58:26.708354 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:26.708910 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:30.326779 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:30.326886 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:34.008853 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:34.009046 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:37.643615 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:37.643653 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:41.257730 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:41.257808 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernelwhere
Code:172.17.10.10 is the docker0 interface on the physical container e. g. on the real-metal Asterisk, "outside" the container
172.17.10.11 is the eth0 interface of the docker internally "inside" the container
172.16.10.1 is the eth0 interface on the bare-metal Asterisk instance that hosts the docker daemon running the kylemanna/openvpn/ container.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
Quote:
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
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.
Code: tcpdump -i docker0 -c 20 -nn port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on docker0, link-type EN10MB (Ethernet), capture size262144 bytes
14:58:26.708354 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:26.708910 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:30.326779 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:30.326886 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:34.008853 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:34.009046 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:37.643615 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:37.643653 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
14:58:41.257730 IP 172.17.10.11.65192 > 172.16.10.1.5060: SIP: REGISTER sip:172.16.10.01:5060 SIP/2.0
14:58:41.257808 IP 172.17.10.10.5060 > 172.17.10.11.65192: SIP: SIP/2.0 401 Unauthorized
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernelwhere
Code:172.17.10.10 is the docker0 interface on the physical container e. g. on the real-metal Asterisk, "outside" the container
172.17.10.11 is the eth0 interface of the docker internally "inside" the container
172.16.10.1 is the eth0 interface on the bare-metal Asterisk instance that hosts the docker daemon running the kylemanna/openvpn/ container.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
Quote:
| SIP/2.0 401 Unauthorized |
-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