>From a security standpoint, why would an organization that strictly controls its firewall allow you to have a system straddle their demarcation with your server? If they don't control the security of it, you've just bypassed their firewall and allowed a back door route into the network that's probably a lot easier to compromise than a real firewall. How can they be assured that it is indeed protected / patched / etc? So one system gets compromised and it's off to the races.
All that is required here is that you allow 5060 udp (for remote workers), 5080 udp (for SIP trunks) and 30000-31000 udp (for RTP/voice) to be NAT translated from an outside IP address to your internal IP address. If you are that daring with your PBX, why don't you just put your whole PBX out in the wild? That's what you are really talking about doing anyway with a leg outside and a leg inside. I'm afraid the multiple interface argument is a bit of a moot point and there are bigger fish to fry (like the ACD). If you need a system to have a leg outside and a leg inside, I started some work with pfSense/freeswitch that might help in relaying that traffic back and forth for you... but as you indicate, it is another box which adds complexity and another failure point. http://sipxecs.blogspot.com/2009/09/pfsense-with-freeswitch-for-sip-trun ks.html Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carmi Weinzweig Sent: Saturday, September 12, 2009 9:11 PM To: [email protected] Subject: [sipx-users] Fwd: I Can Make Calls, But Can't Receive On Sep 12, 2009, at 4:06 PM, M. Ranganathan wrote: > However, nothing can be guaranteed to work unless you are able to > set up port forwarding as Michael has described below. You may well > not be so lucky. Which is once again, why I would want support for two interfaces (one public IP, outside the firewall and one private). > If you cannot setup port forwarding and are not behind a symmetric > NAT, sipxbridge is simply not guaranteed to work correctly. That > configuration will not be supported in general. The product is > geared towards the business environment where control over firewall > settings is a given. There are many business environments where "control over firewall settings" is not a given. Our network is controlled by the University's IT department. I can get public address outside the firewall for any system I have that requires them, as well as internal IP addresses for those devices I do not need or want on the public net. For the project for which I want to use sipX, I have researchers in various other places (including hotels during international travel) as well as faculty and staff in our department. It seems to be your argument that I am better served adding another router/firewall whose sole purpose is to forward sip connections to my internal net (adding cost, complexity and another point of failure) rather than just using the second ethernet interface that my sipX server has for free. I work quite closely with many other Universities and companies and I find that our situation is not unusual. I think it is great that you have enabled this to work with a single IP (where one can configure one's firewall settings and sometimes in other cases). I also think supporting multiple interfaces has value. /carmi _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
