andrewgroup Posted April 6, 2012 Report Share Posted April 6, 2012 We have recently installed our first Soho for a client. To keep expenses low for our clients were are now wanting to support "single" static IP addresses and are putting he Soho behind firewalls. I'd like to propose the following example for discussions... 1. The Local LAN uses the following IP scheme 192.168.100.X (we've chosen this, since many remote phones may be on the common 192.168.1.0, 0.0 network and that might light result in issues. (It kills ipsec VPNs) and assume errors The Firewall is providing all DHCP Services and can also Provide DNS services for specific domains or simply forwards requests to ISP DNS (IE this can be used to create FQDN for phones internally like pbx.fqdndomain.com to point to 192.168.100.99 for the PBX internally while remote phones will see the pbx.fqdndomain.com as the real single static IP address.. The PBX is on 192.168.100.99 The Public IP address is 23.23.23.50 (example) The SIP carrier uses RTP port ranges 10000-30000 The PBX and the local Phones are working fine We like Zyxel Firewalls, but others support SIP too, but we disable SIP ALG.... The problems we are having are one way audio We've followed many tips and wiki posts, but we have no proven solution... SIP replacements, and Routes appear to kill the local phones or the remote phones.... I'd sure be willing to donate whatever time or equipment is needed to come up with a proven Single Static IP address with a Firewall of choice, that reliably supports LAN and WAN phones.... My guess is this first failure is going to cost us the client, the time and the money spent to date, and having the client now request multiple IP addresses from the ISP is off the table... Argg... and all comments or suggestions are welcome... Thanks... Quote Link to comment Share on other sites More sharing options...
Steve B Posted April 6, 2012 Report Share Posted April 6, 2012 We have recently installed our first Soho for a client. To keep expenses low for our clients were are now wanting to support "single" static IP addresses and are putting he Soho behind firewalls. I'd like to propose the following example for discussions... 1. The Local LAN uses the following IP scheme 192.168.100.X (we've chosen this, since many remote phones may be on the common 192.168.1.0, 0.0 network and that might light result in issues. (It kills ipsec VPNs) and assume errors The Firewall is providing all DHCP Services and can also Provide DNS services for specific domains or simply forwards requests to ISP DNS (IE this can be used to create FQDN for phones internally like pbx.fqdndomain.com to point to 192.168.100.99 for the PBX internally while remote phones will see the pbx.fqdndomain.com as the real single static IP address.. The PBX is on 192.168.100.99 The Public IP address is 23.23.23.50 (example) The SIP carrier uses RTP port ranges 10000-30000 The PBX and the local Phones are working fine We like Zyxel Firewalls, but others support SIP too, but we disable SIP ALG.... The problems we are having are one way audio We've followed many tips and wiki posts, but we have no proven solution... SIP replacements, and Routes appear to kill the local phones or the remote phones.... I'd sure be willing to donate whatever time or equipment is needed to come up with a proven Single Static IP address with a Firewall of choice, that reliably supports LAN and WAN phones.... My guess is this first failure is going to cost us the client, the time and the money spent to date, and having the client now request multiple IP addresses from the ISP is off the table... Argg... and all comments or suggestions are welcome... Thanks... I had issues with one way audio, until I put it in the DMZ. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted April 6, 2012 Author Report Share Posted April 6, 2012 DMZ? Could you better define your use of the DMZ? In my example the internal LAN is 192.168.100.X We could create a DMZ port on the Firewall and SET That IP as Range as 192.168.200.X The External WAN interface of the Firewall has a single IP. I assume th Firewall Allow Rule and PInhole (port forward for 5060 goes to the DMZ address that is a seperate port on the firewall...) The LAN phones register against that IP or FQDN.... Your continued thoughts are appreciated.. Thanks Quote Link to comment Share on other sites More sharing options...
Steve B Posted April 6, 2012 Report Share Posted April 6, 2012 DMZ? Could you better define your use of the DMZ? In my example the internal LAN is 192.168.100.X We could create a DMZ port on the Firewall and SET That IP as Range as 192.168.200.X The External WAN interface of the Firewall has a single IP. I assume th Firewall Allow Rule and PInhole (port forward for 5060 goes to the DMZ address that is a seperate port on the firewall...) The LAN phones register against that IP or FQDN.... Your continued thoughts are appreciated.. Thanks In the DMZ settings on your firewall put the IP of your PBX (192.168.100.99) Make sure the SIP replacement is set as 192.168.100.99/23.23.23.50 (your example IPS). Take the port forwards to the PBX out as everything goes to the PBX unless otherwise expected by the router. To register a phone on the WAN to a DMZ I did this: In my instance, I had a hard time auto provisioning this way because the auto provisioning uses the internal IP instead of the external IP (snom may have a way to work this that I am not familiar with). I worked around this by auto provisioning them on the LAN, then turned the updates off on the phone and changed the IP to the external IP of the router. I hope that helps. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted April 6, 2012 Author Report Share Posted April 6, 2012 Thank you for the added comments, I've created a decent Visio Plan documenting a test setup system to share with everyone, but it seems I have little room to upload anything further... I suspect the auto provisioning issue is icmp blockage on the DMZ, we are using Zyxel routers and they have an option to allow ICMP multicasting from DMZ to LAN... I'll know something in a bit, and will see if they can delete my old upload stuff or grant me larger space on the forums. Cheers Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 7, 2012 Report Share Posted April 7, 2012 My input here is that you might have only one physical interface, but that does not imply that you can have multiple interfaces in Linux. You could set up a 2nd IP address and use that one for the DMZ (everything must be done from SSH, sorry no web interface for that kind of stuff). I guess you have seen http://wiki.snomone.com/index.php?title=Server_Behind_NAT, I favour the IP routing lits to get this job done. All in all, your customer might have saved a few bucks on the hardware and software; however having such a complicated setup does cost money unless you work for free. A server needs a routable address. The end of IPv4 is near, welcome IPv6. Hopefully then we dont have to talk about routable IP addresses any more. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted April 7, 2012 Author Report Share Posted April 7, 2012 My input here is that you might have only one physical interface, but that does not imply that you can have multiple interfaces in Linux. You could set up a 2nd IP address and use that one for the DMZ (everything must be done from SSH, sorry no web interface for that kind of stuff). I guess you have seen http://wiki.snomone....rver_Behind_NAT, I favour the IP routing lits to get this job done. All in all, your customer might have saved a few bucks on the hardware and software; however having such a complicated setup does cost money unless you work for free. A server needs a routable address. The end of IPv4 is near, welcome IPv6. Hopefully then we dont have to talk about routable IP addresses any more. I agree on all points with one exception. Designing a reliable method to deploy the Soho on a single Static IP address is only required once, and this gives us a decided advantage in the marketplace. Unlike the traditional interconnect, we focus our sales efforts the long term proactive monitoring maintenance plan as opposed to large margins on the initial sale. All of our system over the years have been very standardized, albiet with dual NIC's, on Windows, CS410, and NEO Linux boxes. The extreme low cost, and great functionality when using Snom Phones, and upgrade path to the SnomOne Plus is a great offering. All of the discovery work is simply an acceptable part of the business plan and we'll be happy to share our results... So far the Lower Cost Zyxel devices are failing to meet our needs due to the inability to control local loopback natting. Working with the Engineering team at Zyxel the USG series has the ability to do what we need. Cheers - Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 8, 2012 Report Share Posted April 8, 2012 I agree on all points with one exception. Designing a reliable method to deploy the Soho on a single Static IP address is only required once, and this gives us a decided advantage in the marketplace. Unlike the traditional interconnect, we focus our sales efforts the long term proactive monitoring maintenance plan as opposed to large margins on the initial sale. All of our system over the years have been very standardized, albiet with dual NIC's, on Windows, CS410, and NEO Linux boxes. The extreme low cost, and great functionality when using Snom Phones, and upgrade path to the SnomOne Plus is a great offering. All of the discovery work is simply an acceptable part of the business plan and we'll be happy to share our results... So far the Lower Cost Zyxel devices are failing to meet our needs due to the inability to control local loopback natting. Working with the Engineering team at Zyxel the USG series has the ability to do what we need. One of the points of the SoHo is that we are using a standard platform, so that all features are available to the installer. In the first versions of the SoHo, we attempted to privide all features through the web interface. But we had to give up. There are so many features today (VPN, VLAN, 802.1X, 2nd IP, 3rd IP, DHCP server(s), web servers, SNMP, you name it), and it is impossible to have them all through the web interfaces. The debian documentation is excellent and there is no point to copy it. Instead, it is better to offer the installer a standard login through SSH, and tten everything else is just a debian computer. The only thing specific is actually the PBX, and thats what we need to program & document. By keeping the focus on this component we can make sure that we have a collection of outstanding components instead of one so-so attempt to solve all those problems. Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted April 9, 2012 Report Share Posted April 9, 2012 IP routing lists should work, I used it many times with Zywall's example 192.168.100.0/255.255.255.0/192.168.100.250 0.0.0.0/0.0.0.0/23.23.23.50 this should fix your audio and local and remote phones. port forward all used ports to the pbx IP. Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted April 9, 2012 Author Report Share Posted April 9, 2012 Thanks all, this may not be the perfect solution, but added the public IP alias to the Soho, removed the 192.xxxx LAN gateway, IP replacements were added, along with routes and appears to be OK. Seems to require the remote phone ports forwarded to the PBX. We will take another look to further simplify the install, but this seems reasonable in light of the goal... Once we regain some space on our upload portal, we'll provide better docs.... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.