Connecting VOIP phones behind a RED to PBX/SIP behind UTM on different subnet.

Dave, I suspect the salesman for your provider is ignorant of how the RED devices function.  In Standard/Unified, your PBX shouldn't be able to tell whether a phone is two feet away or behind a RED 100 miles away.  What happens if you move an existing phone to one of the locations?

Cheers - Bob

If the Phones get the PBX IP via dhcp you just need to add the according dhcp Option to the REDs dhcp range and point it to the existing PBX. Done. Also they MUST have an ip in the RED ip range. else it won't work.
I can't imagine that the PBX can't have a gateway on the internal network to accept phones from another subet. if so i would throw this thing out and get a proper pbx.

Also make sure the firewall on the UTM allows voice traffic from RED > PBX AND RED > other internal phones and vice versa. with VoIP phones often send data directly to each other.

We have the same setup with remote phones running through a RED tunnel to our main pbx. woks like a charm.

I sadly have no direct access to the PBX as it is "ran" by the provider. The present phones are pointed at the PBX's IP and their config file (from what I can piece together) is based on their MAC address and this address has to be setup on the PBX software by the provider. So I can say I need this MAC setup on the PBX and as long as their system has a config for the device (is allowed on their system) it gets in.

I would love nothing more than to remove/replace the system, but I don't control the budget and this one is "cheap and works", in managements eyes.

The scary part is, the VAR (not the manufacturer) is a Sophos partner, which is why I stated the ultimate goal seems to be upselling and more/additional, re-occurring monthly "service" revenue. I don't want to preach, but the tech vendors are going the way of the game developers and other services. This mainly being that everything is a starter (incomplete) offering, features that existed are now addons and you are renting/subscribing anything you need.

The remote office in question is over 1000 miles away, so not as easy as try it. However, I do have another office closer by with a RED15 on it that I can try. Another crazy question that is related, would another UTM be able to be similarly "configured" as a RED to do the same? We have another larger office with the same phone system already in place with a UTM that is IPSEC s2s VPN connected.

I'm looking to put together a proposal for management that involves replacing or 2 UTMs at HQ, 1 UTM at previously mentioned office, with 3 newer models and then shuffling around our RED 50s to the RED 15 locations, and swapping the 50's with our present UTMs.

Added question related to main question and an update: How would the addition of VLANs effect the use of the phones behind the RED device? I just remembered that the other site I was going to test with has another "mini/slave pbx" in use and I know the provider is using 2 VLANs (voice and data) as all traffic goes through their Cisco switches and then our switches and RED. 

So, I have done some simple testing from the remote site back to here (ping and tracert) and I'm not sure a remote phone would work as the VAR keeps insisting that the PBX and devices must be on a FLAT network. The PBX was not pingable and the tracert timed out from the remote side. Doing the same ping and tracert to a server on the same subnet as the PBX did return results.

Doing some more poking around, and remembering some comments from office managers who have access to the PBX GUI as well and complain they can't access the GUI over our SSL VPN, the PBX appears to try and redirect traffic bound for the GUI to an internal (to it) address. For example, entering in the PBX address even while on the same subnet: URL: http://10.200.200.10 (PBX) causes it to time out and the URL changes to:

We manually have to change the address to: http://10.200.200.10:8008/cgi-bin/cpconf?_m=0030 ..... to have it work. Is there any rules or settings on the UTM that I can create to compensate for their "bad" addressing/routing?

I'm nearly (well I've been at the point for a while now) at removing the entire solution and replacing it with our own ASTERISK, FREEPBX or FREESWITCH and our existing hardware and Linphone for a soft-phone. Then I remember that I'm already stretched thin. :)

Yes, Dave, you can make a RED tunnel between two UTMs. Using an IPsec tunnel wouldn't do what you want.

I didn't follow the issue with the URL change, but maybe accessing via a RED tunnel would solve that problem.

Cheers - Bob

Hey Bob. All the tests where done via a RED tunnel.  I'm guessing this is an issue with subnet (remote) talking to a subnet (UTM) talking to another subnet (PBX has 2 ethernet interfaces - one on the UTM the other to the Partner's ADSL).  I'm thinking at this point it will be easier to let them "win" and have their monthly fees.

This must be a routing issue, Dave.  I'm confused by the diagram that sows what looks like two PBXs.

Cheers - Bob

Bob,

The set (red boxed now too) on the left is what the VAR is trying to sell us, and the one on the right (red arrow pointing to it) is what we have now. Present one (red arrowed) has two IP's (potentially 3 as it is on their own ADSL service). The 10.200.X.10 address it has was assigned by us and the 192.168.0.10 is what they use "internally" on the PBX and we can't change.  When we want to make changes to what we can (extension names, menu options etc) via their portal we go to 10.200.X.10 which then seems to use the 192.168.0.X range internally to them.