TIPS Install OpenVPN on IncrediblePBX 13-13

[wardmundy]

Reminder: Don't forget to adjust your client firewalls to allow OpenVPN connections. On Incredible PBX 13-13 CentOS and Ubuntu platforms, this will do the trick:

iptables -A INPUT -s 10.8.0.0/24 -j ACCEPT
echo "iptables -A INPUT -s 10.8.0.0/24 -j ACCEPT" >> /usr/local/sbin/iptables-custom

 

[jerrm]

Reminder: Don't forget to adjust your client firewalls to allow OpenVPN connections. On Incredible PBX 13-13 CentOS and Ubuntu platforms, this will do the trick:

iptables -A INPUT -s 10.8.0.0/24 -j ACCEPT
echo "iptables -A INPUT -s 10.8.0.0/24 -j ACCEPT" >> /usr/local/sbin/iptables-custom

Good point. I elected not to add the rule automatically. iptables-custom already allows the range by default. If someone has customized it, I assume they know what they are doing. Worth making a note in the setup though.

 

[wardmundy]

@jerrm: For those that implemented a Google Cloud-based server, we had to shrink the iptables rule from 10.0.0.0/8 to 10.0.0.0/24 to block access by other Google Cloud users. So it's probably safer to add the 10.8 rule back in just to avoid a surprise down the road.

 

[jerrm]

@jerrm: For those that implemented a Google Cloud-based server, we had to shrink the iptables rule from 10.0.0.0/8 to 10.0.0.0/24 to block access by other Google Cloud users. So it's probably safer to add the 10.8 rule back in just to avoid a surprise down the road.

OK. Will update soon.

 

[wardmundy]

Good News: We've now got the OpenVPN Client working with Incredible PBX for the Raspberry Pi. See the revised Nerd Vittles tutorial for details.

 

[wardmundy]

The linked script assumes all client traffic is pushed through the VPN. Probably not desirable by default. An endpoint or management pc could connect to many open internet devices and we wouldn't want that traffic passing through the pbx - from both a security and performance perspective.

If the purpose is for endpoints and management, do we need to worry about pushing local dns at all - or could we could just point to the server's openvpn ip? What does the current neorouter setup do?

Circling back around on this. As now configured, both the OpenVPN and NeoRouter VPN implementations as documented on Nerd Vittles are pretty much the same. You install a VPN server and then point VPN clients at that server for login. It's purely a star topology with both VPN platforms. Once a client logs in, the server is pretty much out of the picture completely. A logged in client can connect to any other logged in client directly without going through the server (I think). All traffic flows between the two clients. And, on a client machine, access to non-VPN addresses using either a LAN IP address or Internet address, will never hit the VPN server at all. The one thing that NeoRouter has that I wish OpenVPN had is a client query utility (GUI or CLI) that shows all the connected and disconnected clients. You can get the info (updated every minute) on the OpenVPN server (cat /var/log/openvpn/status.log), but it isn't available on any of the OpenVPN clients. I may try to build a simple web app that's only accessible at 10.8.0.1 with a symlink to this status log.

UPDATE: The web status page has been added to the Nerd Vittles tutorial now.

To answer your question, I don't think we need to push out local DNS from the client at all. You can connect to any VPN client directly by IP address.

Is this star setup the same way your script works?? If not, can you document what is different? Thanks for all your work on this!

 

[jerrm]

Once a client logs in, the server is pretty much out of the picture completely. A logged in client can connect to any other logged in client directly without going through the server (I think). All traffic flows between the two clients.

OpenVPN is not a mesh topology. All client-to-client traffic passes through the central server

on a client machine, access to non-VPN addresses using either a LAN IP address or Internet address, will never hit the VPN server at all.

Correct, now that we aren't pushing the default gateway.

To answer your question, I don't think we need to push out local DNS from the client at all. You can connect to any VPN client directly by IP address.

My leaning is not to do it:

• It could be nice for dedicated phones - all endpoints could use dns names, allowing iptables rules and asterisk to check the host name. One setup for all, but... we can still use the internal LAN IP for all.
• Very questionable for softphones - you don't really need the pc/device using the VPN for all dns queries. Again, name based setup is nice, but pushing dns can break things if the client device needs to access it's own LAN devices by hostname.
• Convenient for management if passing traffic to the LAN, all internal host names can be resolved, but my thoughts for an on-the-pbx install is targeting just endpoints and pbx management.

Ideally OpenVPN would have a built-in way to push a hosts file as an in-between. I don't think it does. It can be handled via an up script, but that's beyond the KISS scope.

 

[wardmundy]

OpenVPN is not a mesh topology. All client-to-client traffic passes through the central server

Learn something every day. I actually watched the Vultr server monitor and didn't see any network traffic, but it obviously isn't too accurate.

I went ahead and added a web status page to get a list of active VPN clients. Install instructions have been added to the Nerd Vittles tutorial since hash marks blow up in the forum now.

 

[wardmundy]

Lessons Learned

I thought I'd share a couple discoveries we've made this week during the rollout of OpenVPN.

First, we started wondering how we would ever migrate the OpenVPN Server to a different provider. Bottom Line: As configured, you can't because, unlike NeoRouter, the server IP address gets pushed out in every client config. So, if the server IP address changes, every client config has to be modified and reinstalled. This is quite different than NeoRouter where the client simply logs in to a different IP address after cloning the NeoRouter Server to a different platform. We will be adjusting the tutorial to strongly recommend that folks set up their server with an FQDN instead of an IP address. While the install script prompts for an IP address, it will accept an FQDN without balking. If an FQDN is entered, the OpenVPN server script then generates clients with the FQDN instead of the server IP address. Still not quite sure how to clone the OpenVPN server setup, but we'll continue to work on that.

Second, we never intended to route all client network traffic through the OpenVPN server. We found a workaround for non-VPN traffic by tweaking the install script for client generation with the addition of pull-filter ignore "redirect-gateway". Unfortunately, an iOS bug ignores this command on iPhones and iPads. A better solution which also works with iOS is to remove the redirect-gateway commands from the server itself BEFORE the script is first run:

sed -i "s|\techo 'push \"redirect-gateway|#\techo 'push \"redirect-gateway|" /root/openvpn-install.sh
sed -i "s|push \"redirect-gateway|#push \"redirect-gateway|" /root/openvpn-install.sh

If you've already installed the server, then you can remove the redirect-gateway line from the /etc/openvpn/server.conf file and restart your server:

systemctl restart [email protected]

Then the pull-filter command can be removed from /etc/openvpn/client-template.txt and all of your previously generated .ovpn configs as well.

 

[jerrm]

I thought I'd share a couple discoveries we've made this week during the rollout of OpenVPN....

Agree - FQDN with a short ttl is best.

 

[markd89]

I've been hacking on this, thanks @jerrm

The install went fine on Centos 7.

During install, I did not use a FQDN. Can I make that change in client-template.txt or is it better to reinstall? I made an image with Vultr before installing so it's no problem at this point to re-do it.

Thanks,
Mark

 

[KNERD]

Reinstall? That would be like reinstalling the Word Processor just to make a change in the spelling of a word. Just change the config file.

 

[markd89]

Reinstall? That would be like reinstalling the Word Processor just to make a change in the spelling of a word. Just change the config file.

hahahaha, thanks! (I didn't know if that IP/server name was cooked into the encryption stuff)

Thanks again!

 

[jerrm]

I've been hacking on this, thanks @jerrm

The install went fine on Centos 7.

During install, I did not use a FQDN. Can I make that change in client-template.txt or is it better to reinstall? I made an image with Vultr before installing so it's no problem at this point to re-do it.

Thanks,
Mark

Editing the template should be fine.