Dealing with firewalls

Normally, the endpoints of a private cloud are not exposed outside the private network of the organization. Users that need to access these endpoints from outside the organization usually resort to some Virtual Private Netork (VPN) solution. This allows them to establish a secure connection between the access machine sitting outside the organization's private network and the machine running the cloud orchestrator sitting inside it.

Fogbow aims at being as non-intrusive as possible. Thus, the deployment of Fogbow services should not require unreasonable changes in the security policies of the federated sites. In particular, the endpoint of the Fogbow resource allocation service (RAS) running at a particular site of the federation (and any other auxiliary service that might also be deployed) should not be exposed outside the private network. These should only be accessible from outside the private network of the organization via the setup of an appropriate VPN. This poses the problem of how federation users that are associated to a given site of the federation can access the endpoints of the Fogbow services running at the other sites. Obviously, it is not feasible to allow them to establish a VPN between their access machine and the machines running the Fogbow services at these sites.

To solve this problem, the Fogbow services running at different sites communicate with each other using a firewall-friendly messaging service. In particular, this service allows the Fogbow RAS running at a user's site to route her/his requests to the RAS running at the remote sites that should provide the resources to the user.

Fogbow's messaging service uses the XMPP protocol. Thus, services that need to communicate with their counterparts running at remote sites are implemented as XMPP components. These are clients of XMPP servers that are deployed at the DMZ of each federation site, ie. outside the organizations' private networks. XMPP clients send messages to their local XMPP server, which in turn routes the request to the appropriate destination XMPP server running at the DMZ of a remote site. These servers are in charge of delivering the messages received to the appropriate client running in their site.

XMPP servers usually expose port 5269 at the DMZ so that they can reach (and be reached by) any other XMPP server. XMPP components are assigned logical, DNS-resolvable addresses, and message packets exchanged among them are multiplexed through the server-to-server port exposed by their respective XMPP servers.