Could you provide more info why this is not good practice?
As an overview (as the subject is way to in depth for online text)… a routing table needs an absolute to route data, to do this a single gateway should be used (if its not local, then its gateway time).
The problem is, any device having a gateway has a return route, so a single box with 2 gateways (multihoming) now has 2 routes to the same destination, so if a single packet finds its way to both outside IP address, they both end up at the single inside box, how does it deal with this? well it cant, that should never be allowed to happen on any LAN. so its a disaster waiting to happen, IP storming and all other nasty network events happen.
Even when its controlled, it still happens with load balancing firewalls, i see it all the time with VPN tunnels, they have ways to deal with this, and events to test the new requests to confirmed which route to use.
After a further (many 10’s of) hours of testing we have managed to get a GXP21xx to VPN in with the genuine openVPN server. Its VERY messy but it does work* (read more on this at the end), i have not posted all the details here as this post would be pages long, below is an overview:
- Downloaded the VMWare version of the openVPN server
(the server can be had on a few flavours of Linux (self build), Hyper V and VMWare (Both built ready to use)
- Limited to 2 clients free
- DHCP IP address pool to push to the clients
- Single Ethernet connection (LAN) (WAN is not needed as this is not a firewall, IP routes have to be created on the devices to allow the traffic outbound)
- Static IP address + gateway to a firewall for internet
- NAT added for the firewall
- Above VPN IP address pool added to the LAN list in the PBX
- Zero Config allows the above VPN IP Address pool from the VPN
- Route added for the above VPN IP address pool back to the static IP address of the openVPN server (this is the messy part) (this negates the need of multi homing (more than 1 gateway)
- Has a port forward of 1194 to a virtual openVPN server (which will be the openVPN server)
- You will NOT be able to ping ANY phones (or administer the web interface) from ANY desktop PC on the LAN unless a route is added to the Windows PC the same as the PBX has, this would have been negated if the VPN was inside the firewall (as all desktops would use this as the gateway)
- If testing this with a remote Windows machine (to make sure the openVPN server is working), turnoff the firewall on the remote machine, it will not return ping even with a route added to the local machine.
We have called the phone and it does ring
It will reboot from the PBX
It will return ping to the PBX (UCM)
It will trace route correctly inside the PBX (UCM)
.>> This DOES work for voice as well, been tested and in use <<
The whole setup took about 2-4 hours (excluding all the testing), however that assumes:
The PBX is working
The phone is already remote and able to be accessed (for config)
Have a working VMWare server already on the LAN
GOOD knowledge and working understand of firewall rules, IP routing and VMWare.
>> All of the above would not have been needed if the PBX had the VPN server built in <<
Things we have noticed while doing this
- COMPRESSION, not sure why Grandstream have this in the phone, its deprecated as posses a security risk when used, its been officially dropped by openVPN
The above is the reason it was not working with Watchguard firewalls who have adhered to openVPN, the connection will not be permitted if the “comp-lzo” command is anywhere in the initial request (even if the request has it set to off, which would include on, off or adaptive)
- Phones do not work with Watchguard openVPN, however after talking with Watchguard by my request they are going to talk with Grandstream to see if they will “officially” support there hardware for VPN, this would be at least 6 months out even if they want to
- Does not work with QNAP VPN (QVPN) (not enough certificates are produced)
- Have not tested with DD-WRT firewall firmware, however the certificates (all 4) needed to be created manually outside the firmware which adds time to the testing so was going to be looke at after the above (which works), i do have a DD-WRT hardware, ive not tested it
The reason this is all messy:
- It adds another server in the mix (openVPN server), (VMWare or another hardware unit)
- Adds the need of a really squeaky clean network as the traffic as more servers to hit and get out the door
Below are the routes IF the VPN server was inside the PBX or permiter firewall
Phone >internet> Firewall (VPN server) >lan> PBX
Phone >internet> Firewall >lan> PBX (VPN server)
Benefits are no added routing, less possible packet loss, way easier to administer and deploy
The route used when another VPN server is outside existing hardware
Phone >internet> Firewall >lan> openVPN server >lan> PBX (with route added to the VPN server)
This adds to the stress of the VMWare server, it also adds to possible packet loss (due to LAN use and extra hardware (VMWare in my case), it also means the phones can not be administered from the LAN with out extra routing added to every desktop that needs to access the phones.