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 <[email protected]> 01/03/09 6:31 PM >>>    Looking at 
>>> the questions and setup notes, using the Vyatta and OpenSBCsolution would 
>>> be a good start. Run that server as the firewall, SBCand OpenVPN solution 
>>> all in one, this would encrypt traffic over thenetwork as long as each 
>>> building had its own Media server (also behindthe above setup) Running it 
>>> all as an HA system within the VPN wouldmean it is all encrypted over IP.

The only problem I see could be a slightly higher ping time and thesetup would 
have to be forced routes through openSBC. This would workfor Internal calls 
between buildings, but once the signal enters thePSTN it would require the 
other end to run encrypted lines to stopeavesdropping.

If this case were to be set up correctly then the only thing that couldcause 
eavesdropping would be internal breaks in the network, so accessto the VPN 
would have to be limited to Admins only. Setting the VPN upon 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 torun end to 
end security for other things like internal messaging andcalling through 
desktop programs. This was not easy as the end user isbasically not security 
concious as it "isn't My job" mentalitycontinues to function.

Regards

Alan

Online Systems wrote:http://list.sipfoundry.org/mailman/listinfo/sipx-users  
</[email protected]>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users

Reply via email to