Woof! At the moment, sipXecs has several different methods to secure non SIP TCP/IP communications amongst its processes.
Some of them use https directly and have TLS keys and certs, and authenticate either as a user with PIN, a special user with PIN, or via a "shared secret". The best examples of this are sipXconfig and sipXrest. Some of them use ssh-tunnels and port forwarding, such as POSTGRES access for CDRs. Some of them do not use TLS, but only accept connections from localhost, such as sipXivr, or FreeSWITCH (which has a trivial authentication scheme). And some of the FreeSWITCH ports are wide open to the world (the XML-RPC one, I believe). As we move to a more distributed model, and use FreeSWITCH more and more, we need to enable access to the FS ports across machines (for example conference recording and the IM bot both need remote access to FreeSWITCH). In addition, we keep having to add TLS to each and every process that needs it, adding complexity (which is why it isn't in sipXivr yet, as I got fed up mucking about with keystores and certs!) Instead of having each process implement it's own TLS, I was wondering if it would make more sense to have some kind of standard VPN setup between all hosts in a cluster. This way, host to host communications is secured and authenticated, and so we don't have to do it again for each process. This would also enable secure access to the third party processes like FreeSWITCH and POSTGRES which don't do TLS by themselves. Non-public facing applications would bind only to the "VPN" address or "localhost", and thus would not accept connections from outside the VPN. I must admit, I don't know enough about setting this up to make a stab at a proposal as to how to implement this. I'm thinking along like lines of OpenVPN. I know some of you are already VPN experts from previous lives, and hopefully you can help make sense of it all. I'm envisioning a configuration that would create and maintain tunnels at boot time from each host to every other host in a cluster, and set up the routing so everyone can just talk as if they were on a LAN. Host names could be standardized (possibly based on roles?) and entered into /etc/hosts or DNS (by sipXconfig, natch), so if a process needs to access a process on a remote machine via the tunnel, it would connect to say "proxy2" or "conferencebridge3" which would map to the tunnel'ed IP address of the machine fulfilling that role. Perhaps hostnames wouldn't be needed at all, as sipXconfig would already know all the VPN IP addresses and put them in all the correct places in the individual config files. Is this type of scheme possible? Does it make any sense, or am I rambling incoherently in an H1N1 induced haze? --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
