Reconfigurable Firewall

In IPv4, all communications from inside Grid'5000 to the outside internet are NATed to the single public IP address of Grid'5000. It is possible to initiate a network connection from inside Grid'5000 to the outside internet and the connection tracking of the Grid'5000 firewalls will allow the communication to work in most situations (i.e. for protocols that are supported by standard connection tracking mechanisms).

But two things are not possible, in IPv4:

• Initiating a direct network connection from the outside internet to the inside of Grid'5000 (by direct connection we mean not through VPN or ssh tunnel). It is impossible to allow such connections since Grid'5000 hosts do not have a public routable IPv4 address.
• having connections initiated inside Grid'5000 to the outside internet, on protocols which are not supported by standard connection tracking mechanisms ("standard connection tracking mechanisms" is deliberately vague, it depends on the specific firewall version which may change).

In IPv6, all Grid'5000 hosts have a public, globally routable IPv6 address, and there is a Reconfigurable Firewall service which allows users to request firewall openings for specific IPv6 addresses, allowing connections initialed in the outside internet to target specific IPv6 addresses inside Grid'5000. This page discusses the usage of this Reconfigurable Firewall service.

Functionnalities

The Reconfigurable Firewall (aka Dynamic Firewall) service is called g5kfw. It provides a REST API allowing:

• To request firewall openings associated with an OAR job. The request is checked to ensure that the requested openings only targets IPv6 addresses of nodes which belong exclusively to the OAR job (It is not possible to request an opening to a shared resource)
• There can be several openings associated with an OAR job.
• At the end of the OAR job, all openings are removed.
• An opening is:
  • A list of destination hostnames (which resolve to IPv6 addresses) or IPv6 addresses. These are the addresses of the hosts inside Grid'5000 for which a connection from the outside internet will be allowed,
  • The kind of protocols opened. There are two kinds of protocols:
    • "tcp+udp": will open only for TCP / UDP flows. In this case, the list of TCP/UDP ports or port ranges that are to be allowed are also needed. "tcp+udp" is the default.
    • "all": means open any protocol, meaning any IPv6 packet are allowed. In this case, there is no concept of ports.
  • Optional source hostnames (which resolve to IPv6 addresses) or IPv6 addresses (/128) or networks, to restrict the opening to specific sources outside Grid'5000. If nonde given, there is no restriction.
• Additionally, for any destination for which an opening is requested, ICMPv6 is also automatically unfiltered.

API details

The Grid'5000 API base URL is of the form https://api.grid5000.fr/<api_version>/, The reconfigurable Firewall API resource URLs are of the form https://api.grid5000.fr/<api_version>/sites/<site>firewall/<jobid> where <site> <jobid> where <site> <jobid> are the site and jobid of the OAR job for which one requests openings.

There are two operations than can be performed on these resource URLs:

• POST: adds openings to the current openings for the OAR job. The openings are given in the POST body as a json payload, with the format:

[
  {
    "addr": "space separated list of hostnames or ipv6 host (/128) addresses" or array of,
    "port": (mandatory if proto=="tcp+udp", fobidden if proto=="all") integer, or "space separated list of ports or port ranges" or array of. A port range is in the form "port1..port2",
    "proto": (optional) protocols to open, can be "tcp+udp" (the default) or "all"
    "src_addr": (optional) same as addr, for source addresses. Also possible to pass IPv6 network addresses (/x with x < 128)
  },
]

• DELETE: delete all openings for the OAR job.

The request is checked:

• check that user making the request has permission on the job
• for an opening add request, check that the requested destination addresses all belong to the job
• for an opening add request, check that the job has started

If the request is accepted, a success code is returned, which can be 200 if all the firewalls could be immediately configured, or 202 if one or more of the firewalls could not yet be configured. If one of the firewall could not be immediately configured (maybe there is a network issue, or the firewall is rebooting...) the service will retry to apply the opening every X seconds (X currently being set to 60 seconds)

If the request is refused or fails for any reason, an error code is issued (4xx or 5xx), and the response body contains a message with an explanation of the error.