There was just a question on the Vyatta forum about prioritizing in the tunnel: http://www.vyatta.org/forum/viewtopic.php?t=1323
This sounds like a pretty plausible solution. Setup a firewall directly in front of the PBX & gateways and then all phones nail up an IPSec connection to the firewall. There you go. Then all you need to do is worry about physical security (bribing the maid as Scott put it). Snom has the much nicer looking 820 out: http://sipxecs.blogspot.com/2008/12/new-snom-820.html Mike From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Saturday, January 03, 2009 6:40 PM To: [email protected] Cc: [email protected] Subject: Re: [sipx-users] Talking about encryption It would also mean the firewall needs to sit in front of all the private network traffic (site-to-site), and the Firewall would have to shape and prioritize any traffic between sites giving highest priority to the VPN, with the VPN carrying primarily your sip traffic. I am doubtful that the vyatta/openvpn solution is mature enough to be able to shape or prioritize traffic "inside" the vpn tunnel itself. But since the aim was to encrypt the traffic, then, yes, a vpn makes the best sense. Or just using a central solution/sipxecs server, perhaps clustered depending on your overall load, and using OPENVPN and SNOM 370 handsets with the vpn client tarball, this would make your management points fewer, and perhaps more manageable. This way the traffic ic encrypted to the handset itself. Centrally protecting the main sipx server and your gateways might be easier if they were in a central location too. >>> Alan Denby 01/03/09 6:31 PM >>> Looking at the questions and setup notes, >>> using the Vyatta and OpenSBC solution would be a good start. Run that >>> server as the firewall, SBC and OpenVPN solution all in one, this would >>> encrypt traffic over the network as long as each building had its own Media >>> server (also behind the above setup) Running it all as an HA system within >>> the VPN would mean it is all encrypted over IP. The only problem I see could be a slightly higher ping time and the setup would have to be forced routes through openSBC. This would work for Internal calls between buildings, but once the signal enters the PSTN it would require the other end to run encrypted lines to stop eavesdropping. If this case were to be set up correctly then the only thing that could cause eavesdropping would be internal breaks in the network, so access to the VPN would have to be limited to Admins only. Setting the VPN up on a different subnet would also go towards making it more secure. This is a possible solution that I have not tried, but I have had to run end to end security for other things like internal messaging and calling through desktop programs. This was not easy as the end user is basically not security concious as it "isn't My job" mentality continues to function. Regards Alan Online Systems wrote: Hello, You may be better off just tacking up site to site VPN's via appropriate endpoint hardware between your locations and compartmentalizing your traffic. This should take care of your site to site calling and will flatten your voice network a bit which should make it easier to manage centrally. You might also want to do a quick analysis of how much it will cost to purchase a few switches (10/100 stackable managed should be fine for most, after all you are talking about 90k per call worst case), PoE midspans (optional), network cable if you don't happen to have existing extra jacks at the desks, etc. and physically separate the networks if concerned about security. It also makes monitoring / troubleshooting on the voice network much easier. Buy some patch cord locks to install on the cabling so the patch cables cant be removed from the phones or the wall to prevent unauthorized devices from being installed on the network. Being occasionally involved in higher security installs where the customer is concerned about these sort of issues, it always helps to step back and take a look at the problem from a different perspective. Sometimes there are lower tech, affordable solutions to your obstacles that end up working better than choosing the more complicated solution. Honestly you have a greater chance of someone overhearing your conversation in the next office than listening to your telephone conversation via more sophisticated means, (that is unless you happen to go to work in a heavily armored Faraday cage ever day). I would be very surprised if using such a solution above would even approach the capital or recurring costs of something like a Cisco solution, and am confident that the administration load would be less with a best of breed SipECS solution. Josh [email protected] wrote: Hi Michael, I don't think you'll get all parties (pbx, phone, gateways) to encrypt traffic. that´s really a pitty There's also two different types of traffic that need to be considered for encrypting also... the signaling and the voice traffic. SIPS/SIP over SSL and SRTP... At this point in SIP history if this is a "got to have", you might be better off with a proprietary solution that encrypts end to end. I had to convince my boss not to buy a cisco solution and now you suggest this. The other thing you really need to do is ask yourself, why do I need to encrypt voice on my local network? We have ~ 30 buildings connected via WAN, which doesn´t belong to us. The lines are rented. How much valuable information is being transmitted via voice through a point at which it might be >captured on your local network? Getting access to our LAN is too easy, sadly In general there is much less valuable information transmitted via voice than via data. Well, not in our case If you look at my mentioned cases, where can I encrypt the paths with SIPxecs? _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
