There is an HTCondor machine which is a submit node or an execute node, and you would like to share your new computer resources with others outside your department or division. But, you do not want crooks using your systems to wreak havoc.  So, there is a firewall between your HTCondor resource and the Internet.  Assume that the firewall is a separate host from the HTCondor resource. It is a bastion host running Linux, and the firewall is iptables, with Network Address Translation (NAT). This assumption allows the description to include explicit commands to run.  You or your firewall administrator should translate these instructions to your particular firewall installation.
 
-We are also assuming that you are not going to be using CCB.
-CCB allows communication between HTCondor daemons in a private network (outgoing connections only) with daemons in a public network (bidirectional connections allowed).  It therefore is not a complete solution for a case where you need daemons in two separate private networks to communicate---one or the other network must allow bidirectional connections for CCB to help.  In the case described below, we want a submit node, which is in a private network, to communicate with execute nodes in other private networks, such as Open Science Grid.  This is the private-to-private case that cannot be solved with CCB alone.  The solution below uses port-forwarding to make the submit node effectively public.  This allows the execute nodes in the remote private network to use CCB to have bidirectional connectivity with your submit node.  Bidirectional connectivity could also be achieved without CCB by also applying the port-forwarding solution below to the execute nodes of the remote private network, which may not be possible, either because of your own security concerns or because you do not administer machines on the remote network.
+This example also assumes that you are *not* using CCB.
+CCB allows communication between HTCondor daemons in a private network (outgoing connections only) with daemons in a public network (bidirectional connections allowed).  It therefore is not a complete solution for a case where there are daemons in two separate private networks communicating.  One or the other network must allow bidirectional connections for CCB to help.  In the example case described here, we want a submit node which is in a private network to communicate with execute nodes in other private networks. Open Science Grid works this way.  This is the private-to-private case that cannot be solved with CCB alone.  The solution given here uses port-forwarding to make the submit node effectively public.  It allows the execute nodes in the remote private network to use CCB to have bidirectional connectivity with your submit node.  Bidirectional connectivity could also be achieved without CCB by also applying the port-forwarding solution to the execute nodes of the remote private network, which may not be possible, either because of your own security concerns or because you do not administer machines on the remote network.
 
 Assume that HTCondor is installed and running with the following set up: