Hello, Mature commercial firewalls have this functionality, it takes longer to set up the tunnel than it does to prioritize the traffic in most cases. You still could probably get away with running your voice and data together given the proper switching internally and just adding policy to the perimeter firewalls. An appliance in the range of $500 should be more than sufficient for your application.
Josh Picher, Michael wrote: > > 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] <mailto:[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] <mailto:[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 _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
