Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 5 subscribers
  • Views 6962 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

WABGOR_DAVE

Hello all,

Presently we have 5 small remote offices running REDs on Standard/Unified configs, so that everything is filtered via the UTM here at HQ.  At HQ we have a PBX with approx 35 VOIP phones on it and is capable of handling another 50, easily.  Our provider/VAR (whom I see as just wanting to do the "latest thing" and have monthly service fees coming in and new configuration/contract charge$) is stating that we can't have "directly connected" remote phones, but must instead get another PBX for the remote office and use their "new hybrid" service that will connect new PBX to current one instead. To put it roughly the monthly service costs of 4 phones (not counting hardware charge$) at the remote office will be $10 more a month than what what all 35 of the phones presently used are.  (Example: HQ = $200/m for 35, Remote office would be $210/m for 4)!

There are no VLANs in use, nor QOS (both of which I want to change) so that data and voice have their own limits.  Yes, all remote sites have all their traffic come through HQ, so if our network goes down, so does theirs (something else I'm looking to change eventually).

As I am not a networking genius, but more a lay person+, is there not a way to have the UTM mask all data from 10.71.X.X/24 pointed at the PBX 10.225.X.10 appear to be actually coming from static assigned IPs of 10.225.X.X/24 on the remote phones? To summarize, I would like to have the 4 devices behind the RED have 10.200.X.X/24 IPs and function as if on that network. The problem is that the RED is the gateway device and unless I'm wrong (highly probable), the phones would never communicate out as they would need to have a GW on 10.200.X.X/24, while sitting behind the RED's GW of 10.71.X.X/24

Picture of present config (Blue arrows is current or what I propose happens), what the VAR is trying to sell (Orange arrows and dashed boxes). At HQ the VAR has access to the PBX via ADSL (green arrow) and at our remote office, their "new solution", would ride on our fibre, as this remote office is in a new area and it already cost us $$$ to get fibre in, let alone what the markup on the VAR side for connection would be.



This thread was automatically locked due to age.
Parents
  • 0

    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. :)

  • 0 in reply to WABGOR_DAVE

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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.

Reply
  • 0 in reply to BAlfson

    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.

Children
  • 0 in reply to WABGOR_DAVE

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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.

Unfiltered HTML