Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 5 subscribers
  • Views 5863 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

    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.

Reply
  • 0

    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.

Children
  • 0 in reply to Florian Gall

    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.

Unfiltered HTML