Author Topic: OpenVPN connections not supporting all protocols?  (Read 897 times)

AlecM

  • Zen Apprentice
  • *
  • Posts: 9
  • Karma: +1/-0
    • View Profile
OpenVPN connections not supporting all protocols?
« on: May 15, 2017, 03:50:45 pm »
I've recently migrated my small set of users from an old Window-hosted OpenVPN connection point (which was using bridged mode, via TAP) to a new Zentyal OpenVPN connection, but the new Zentyal-hosted version is giving us some issues.

We have the Zentyal server (version 5) installed as a Secondary Domain Controller within an existing Windows AD network.  It is behind a pfSense-based firewall - so the pfSense firewall is performing the public-WAN to private-LAN port-forwarding/NAT for specific ports.

Our new Zentyal-based VPN problem manifests as some network issues for the client machines (all Windows laptops).  The issues were first noticed in VoIP calls (using an internally-hosted VoIP server, 3CX), where the remote laptop is now getting one-way audio for certain types of call (consistent, see tested scenarios below).  A second observed issue has been network shares not always showing their content properly (content would suddenly disappear then reappear later).

The client computers are all using OpenVPN client 2.4.1 64-bit, running as a Service on system startup to enable the network Route table to be modified (as this requires admin privileges).

Test scenarios for the VoIP call problem:
  • Make a VoIP call from VPN client machine using software phone (3CXPhone) to another internal extension that is also using 3CXPhone - result when the dialled user picks up call is success.
  • Repeat step 1 - result when the dialled user cannot pick up is the call gets directed to Voicemail, but the person who is making the call cannot hear the automated Voicemail menu. (one-way audio).
  • Make a VoIP call from VPN client machine using software phone to an external number - result is the recipient/target will hear the caller, but the caller cannot hear the person they have dialled. (one-way audio).
  • Make a calls from softphone client from LAN that is not using the VPN - all calls work fully as expected.

I ran some wireshark capture on the 3CX server to try and compare the successful calls with the one-way calls, but my knowledge of what to look is not sufficient to really diagnose them properly.

The Zentyal system is running as a QEMU Virtual Machine configured with 6 virtual-CPU and 6GiB RAM on an Ubuntu 16.04 server host.  The Zentyal server is also providing SAMBA shares.

I had originally configured the Zentyal VPN using TUN-mode, but due to the issue I have since added a second config (on a different port) to test using the TAP-mode option.  Unfortunately, the TAP connection version exhibits the same problem.

Note that Remote Desktop Protocol through either tun or tap works very well - hence my topic subject of suspecting the issue relates to specific network protocols.

I cannot seem to find sufficient documentation on the Zentyal WIKI to describe all the option settings for the various modules managed in Zentyal, which is deeply frustrating.  There are guides, but I find that the description of the various settings (why/when to use them and conversely why/when not to) is not discussed thoroughly enough.

Some youtube videos indicate adding network objects for the internal LAN, but don't configure the object - and this seems to be an unnecessary step anyway, as the OpenVPN module automatically adds the internal LAN (10.0.0.0/24) as an advertised network to the VPN server config.

I've wondered if the issue could be the DNS settings, as the Zentyal server is using forwarding to our pre-existing internal Windows DNS host.  It is not configured for transparent cache mode (again, documentation in the WIKI on this feels skimpy to me and doesn't fully describe the pro-and cons of enabling transparent cache mode).

Has anyone else experienced this type of "partial" connectivity with the Zentyal implementation of OpenVPN?