I haven't done replication yet but just out of curiousity I looked at the documentation. It appears that you can do two-way replication if you can be sure that certain conditions (two users updating the same record at the same time on both machines) won't cause data corruption. I can't answer your firewall question because I am just starting to learn about them. I know there is some Perl scripts to manage replication in the Contributed software section of MySQL's web site. If you haven't looked at it, maybe it addresses that problem.
http://www.mysql.com/doc/R/e/Replication_FAQ.html
Q: What issues should I be aware of when setting up two-way replication?
A: MySQL replication currently does not support any locking protocol between master and slave to guarantee the atomicity of a distributed (cross-server) update. In in other words, it is possible for client A to make an update to co-master 1, and in the meantime, before it propagates to co-master 2, client B could make an update to co-master 2 that will make the update of client A work differently than it did on co-master 1. Thus when the update of client A will make it to co-master 2, it will produce tables that will be different than what you have on co-master 1, even after all the updates from co-master 2 have also propagated. So you should not co-chain two servers in a two-way replication relationship, unless you are sure that you updates can safely happen in any order, or unless you take care of mis-ordered updates somehow in the client code.
You must also realize that two-way replication actually does not improve performance very much, if at all, as far as updates are concerned. Both servers need to do the same amount of updates each, as you would have one server do. The only difference is that there will be a little less lock contention, because the updates originating on another server will be serialized in one slave thread. This benefit, though, might be offset by network delays.
