corda/docs/source/firewall-configuration-file.rst

Firewall configuration

File location

When starting a standalone firewall (in bridge, or float mode), the corda-firewall.jar file defaults to reading the firewall's configuration from a firewall.conf file in the directory from which the command to launch the process is executed. The syntax is:

corda-firewall [-hvV] [--install-shell-extensions]
               [--logging-level=<loggingLevel>] [-b=<baseDirectory>]
               [-f=<_configFile>]

Where:

• --config-file, -f: Allows you to specify a configuration file with a different name, or at a different file location. Paths are relative to the current working directory
• --base-directory, -b: Allows you to specify the firewall's workspace location. A firewall.conf configuration file is then expected in the root of this workspace
• --verbose, --log-to-console, -v: If set, prints logging to the console as well as to a file.
• --logging-level=<loggingLevel>: Enable logging at this level and higher. Possible values: ERROR, WARN, INFO, DEBUG, TRACE. Default: INFO.
• --install-shell-extensions: Install corda-firewall alias and auto completion for bash and zsh. See cli-application-shell-extensions for more info.
• --help, -h: Show this help message and exit.
• --version, -V: Print version information and exit.

Format

The firewall configuration file uses the HOCON format which is superset of JSON. Please visit https://github.com/typesafehub/config/blob/master/HOCON.md for further details.

Warning

Please do NOT use double quotes (") in configuration keys.

Bridge setup will log Config files should not contain " in property names. Please fix: [key] as error when it founds double quotes around keys. This prevents configuration errors when mixing keys containing . wrapped with double quotes and without them

Defaults

A set of default configuration options are loaded from the built-in resource file. Any options you do not specify in your own firewall.conf file will use these defaults:

../../bridge/src/main/resources/firewalldefault.conf

Firewall operating modes

Note

By default, the Corda node assumes that it will carry out the peer-to-peer functions of the bridge internally! Before running a dedicated firewall process, it is essential to turn off the dev mode component by setting the enterpriseConfiguration.externalBridge property of the node.conf file to true. If the externalBridge flag is not true, there will be unexpected behaviour as the node will try to send peer-to-peer messages directly!

Assuming that an external firewall is to be used, the corda-firewall.jar operates in one of three basic operating modes. The particular mode is selected via the required firewallMode configuration property inside firewall.conf:

SenderReceiver

selects a single process firewall solution to isolate the node and Artemis broker from direct Internet contact. It is still assumed that the firewall process is behind a firewall, but both the message sending and receiving paths will pass via the bridge. In this mode the outboundConfig and inboundConfig configuration sections of firewall.conf must be provided, the bridgeInnerConfig and floatOuterConfig sections should not be present.

BridgeInner

mode runs this instance of the corda-firewall.jar as the trusted portion of the peer-to-peer firewall float. Specifically, this process runs the complete outbound message processing. For the inbound path it operates only the filtering and durable storing portions of the message processing. The process expects to connect through a firewall to a matched FloatOuter instance running in the DMZ as the actual TLS 1.2/AMQP 1.0 termination point.

FloatOuter

causes this instance of the corda-firewall.jar to run as a protocol break proxy for inbound message path. The process will initialise a TLS control port and await connection from the BridgeInner. Once the control connection is successful the BridgeInner will securely provision the TLS socket server key and certificates into the FloatOuter. The process will then start listening for inbound connection from peer nodes.

Fields

The available config fields are listed below. baseDirectory is available as a substitution value and contains the absolute path to the firewall's base directory.

certificatesDirectory

An optional parameter which specifies directory from which SSL keys and Trust store keys will be loaded from. If missing the value is defaulted to baseDirectory/certificates.

sslKeystore

An optional parameter which specifies the file from which SSL keys stores will be loaded from. If missing the value is defaulted to certificatesDirectory/sslkeystore.jks.

trustStoreFile

An optional parameter which specifies the file from which Trust store keys will be loaded from. If missing the value is defaulted to certificatesDirectory/truststore.jks.

firewallMode

Determines operating mode of the firewall. See above.

keyStorePassword

The password to unlock the TLS KeyStore file (<workspace>/certificates/sslkeystore.jks) containing the node certificate and private key. The private key password must be the same due to limitations in the Artemis libraries.

Note

This is the non-secret value for the development certificates automatically generated during the first node run. Longer term these keys will be managed in secure hardware devices.

trustStorePassword

The password to unlock the Trust store file (<workspace>/certificates/truststore.jks) containing the Corda network root certificate. This is the non-secret value for the development certificates automatically generated during the first node run.

Note

Longer term these keys will be managed in secure hardware devices.

networkParametersPath

This is the file path to a copy of the network-parameters as copied from a node after it has fetched the latest version from the network-map via http. It is used to correctly configure the maximum allowed message size. The maximum message size limit is already enforced by the P2P Artemis inside the node, but the bridge also enforces this before forwarding messages to remote peers and also the float enforces this on received packets. If the size limit is breached these messages will be consumed and discarded, so that they are not replayed forever.

outboundConfig

This section is used to configure the processing of outbound messages. It is required for SenderReceiver and BridgeInner modes and must be absent for FloatOuter mode:

artemisBrokerAddress

The primary host and port for peer-to-peer Artemis broker. This may be running inside to the node, in which case it will hosted on the port of the p2pAddress, or the messagingServerAddress if that is defined and messagingServerExternal is false. Otherwise, it could be an independently run Artemis broker.

alternateArtemisBrokerAddresses

Optionally if there are multiple Artemis broker address e.g. for hot-cold node deployment, then additional hosts and ports may be included in a list.

artemisSSLConfiguration

The default behaviour is that the outgoing TLS 1.2/AMQP 1.0 connections present certificate details from (<workspace>/certificates/sslkeystore.jks)

and validate against (<workspace>/certificates/truststore.jks), using the passwords defined in the root config. However, distinct KeyStores may be configured in this section:

keyStorePassword

The password for the TLS KeyStore.

keyStorePrivateKeyPassword

Optional parameter to lock the private keys within the KeyStore. If it is missing, it will be assumed that the private keys password is the same as keyStorePassword above.

trustStorePassword

The password for TLS TrustStore.

sslKeystore

The path to the KeyStore file to use in outgoing TLS 1.2/AMQP 1.0 connections.

trustStoreFile

The path to the TrustStore file to use in outgoing TLS 1.2/AMQP 1.0 connections.

crlCheckSoftFail

If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.

proxyConfig

This section is optionally present if outgoing peer connections should go via a SOCKS4, SOCKS5, or HTTP CONNECT tunnelling proxy:

version

Either SOCKS4, SOCKS5, or HTTP to define the protocol version used in connecting to the SOCKS proxy.

proxyAddress

Host and port of the proxy.

userName

Optionally a user name that will be presented to the proxy after connect.

password

Optionally, a password to present to the SOCKS5 or HTTP Proxy. It is not valid for SOCKS4 proxies and it should always be combined with [userName].

inboundConfig

This section is used to configure the properties of the listening port. It is required for SenderReceiver and FloatOuter modes and must be absent for BridgeInner mode:

listeningAddress

The host and port to bind to as TLS 1.2/AMQP 1.0 listener. This may be a specific network interface on multi-homed machines. It may also differ from the externally exposed public p2pAddress of the port if the firewalls, or load balancers transparently reroute the traffic.

customSSLConfiguration

The default behaviour is that the inbound TLS 1.2/AMQP 1.0 connections present certificate details from (<workspace>/certificates/sslkeystore.jks)

and validate against (<workspace>/certificates/truststore.jks), using the passwords defined in the root config. However, distinct KeyStores may be configured in this section:

keyStorePassword

The password for the TLS KeyStore.

keyStorePrivateKeyPassword

Optional parameter to lock the private keys within the KeyStore. If it is missing, it will be assumed that the private keys password is the same as

keyStorePassword above.

trustStorePassword

The password for TLS TrustStore.

sslKeystore

The path to the KeyStore file to use in inbound TLS 1.2/AMQP 1.0 connections.

trustStoreFile

The path to the TrustStore file to use in inbound TLS 1.2/AMQP 1.0 connections.

crlCheckSoftFail

If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.

bridgeInnerConfig

This section is required for BridgeInner mode and configures the tunnel connection to the FloatOuter (s) in the DMZ. The section should be absent in SenderReceiver and FloatOuter modes:

floatAddresses

The list of host and ports to connect the available FloatOuter instances. At least one must be present. The active BridgeInner will round-robin over available FloatOuter addresses until it can connect and activate one.

expectedCertificateSubject

The X500 Subject name that will be presented in client certificates from the remote FloatOuter instances.

tunnelSSLConfiguration

Note

For ease of use the TLS default control tunnel connections present certificate details from (<workspace>/certificates/sslkeystore.jks)

and validate against (<workspace>/certificates/truststore.jks), using the passwords defined in the root config. However, it is strongly recommended that distinct KeyStores should be configured in this section to use locally valid certificates only, so that compromise of the DMZ machines does not give access to the node's primary TLS keys.

keyStorePassword

The password for the TLS KeyStore.

keyStorePrivateKeyPassword

Optional parameter to lock the private keys within the KeyStore. If it is missing, it will be assumed that the private keys password is the same as keyStorePassword above.

trustStorePassword

The password for TLS TrustStore.

sslKeystore

The path to the KeyStore file to use in control tunnel connections.

trustStoreFile

The path to the TrustStore file to use in control tunnel connections.

crlCheckSoftFail

If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.

floatOuterConfig

This section is required for FloatOuter mode and configures the control tunnel listening socket. It should be absent for SenderReceiver and BridgeInner modes:

floatAddress

The host and port to bind the control tunnel listener socket to. This can be for a specific interface if used on a multi-homed machine.

expectedCertificateSubject

The X500 Subject name that will be presented in client certificates from the BridgeInner when it connects to this FloatOuter instance.

tunnelSSLConfiguration

Note

For ease of use the TLS default control tunnel connection presents certificate details from (<workspace>/certificates/sslkeystore.jks)

and validate against (<workspace>/certificates/truststore.jks), using the passwords defined in the root config. However, it is strongly recommended that distinct KeyStores should be configured in this section to use locally valid certificates only, so that compromise of the DMZ machines does not give access to the node's primary TLS keys.

keyStorePassword

The password for the TLS KeyStore.

keyStorePrivateKeyPassword

Optional parameter to lock the private keys within the KeyStore. If it is missing, it will be assumed that the private keys password is the same as

keyStorePassword above.

trustStorePassword

The password for TLS TrustStore.

sslKeystore

The path to the KeyStore file to use in control tunnel connections.

trustStoreFile

The path to the TrustStore file to use in control tunnel connections.

crlCheckSoftFail

If true (recommended setting) allows certificate checks to pass if the CRL(certificate revocation list) provider is unavailable.

haConfig

Optionally the SenderReceiver and BridgeInner modes can be run in a hot-warm configuration, which determines the active instance using an external master election service. Currently, the leader election process can be delegated to Zookeeper, or the firewall can use the Bully Algorithm (see <https://en.wikipedia.org/wiki/Bully_algorithm>) via Publish/Subscribe messages on the artemis broker. For production it is recommended that a Zookeeper cluster be used as this will protect against network partitioning scenarios. However, the Bully Algorithm mode does not require any additional server processes. Eventually other electors may be supported e.g. etcd. This configuration section controls these options:

haConnectionString

A string containing the connection details of the master electors as a comma delimited list of individual connection strings.

• To use an external Zookeeper cluster each connection item should be in the format zk://<host>:<port>.
• To use the Bully Algorithm running over artemis the single connection string should be set to bully://localhost.

haPriority

The implementation uses a prioritise leader election algorithm, so that a preferred master instance can be set. The highest priority is 0 and larger integers have lower priority. At the same level of priority, it is random which instance wins the leader election. If a bridge instance dies another will have the opportunity to become master in instead.

haTopic

Sets the zookeeper/artemis topic that the nodes used in resolving the election and must be the same for all bridge instances competing for master status. This is available to allow a single zookeeper/artemis cluster to be reused with multiple sets of bridges (e.g. in test environments). The default value is bridge/ha and would not normally need to be changed if the cluster is not shared.

auditServiceConfiguration

Both FloatOuter and BridgeInner components have an audit service which is currently outputting into the process log some traffic statistics.

loggingIntervalSec

This is an integer value which controls how frequently, in seconds, statistics will be written into the logs.

artemisReconnectionIntervalMin

If connection to the local Artemis server fails the initial reconnection attempt will be after [artemisReconnectionIntervalMin] ms. The default interval is 5000 ms. Subsequent retries will take be exponentially backed off until they reach [artemisReconnectionIntervalMax] ms.

artemisReconnectionIntervalMax

The worst case Artemis retry period after repeated failure to connect is [artemisReconnectionIntervalMax] ms. The default interval is 60000 ms.

p2pConfirmationWindowSize

This is a performance tuning detail within the Artemis connection setup, which controls the send acknowledgement behaviour. Its value should only be modified from the default if suggested by R3 to resolve issues.

enableAMQPPacketTrace

Set this developer flag to true if very detailed logs are required for connectivity debugging. Note that the logging volume is substantial, so do not enable in production systems.

healthCheckPhrase

An optional Health Check Phrase which if passed through the channel will cause AMQP Server to echo it back instead of doing normal pipeline processing. This parameter can be used to facilitate F5 "TCP Echo" health-check monitor. Only when TCP posting starting with healthCheckPhrase in UTF-8 encoding is sent to application port the server will echo the same pass phrase back.

Complete example

As an example to show all features the following is a walk through of the configuration for a pair of HA hot-cold Nodes, connected to by a HA hot-warm set of BridgeInner and FloatOuter that use some simple certificates to secure the control tunnel and a SOCKS5 proxy for outgoing connectivity (see diagram). This is also the recommended full enterprise deployment pattern, although there are plenty of alternative deployment options.

In this example it is assumed that the corda nodes are deployed on nodeserver1 and nodeserver2 using Azure SQL Server nodeda.database.windows.net/corda as clustered storage. The BridgeInner instances run on bridgeserver1 and bridgeserver2. The SOCKS5 proxy is at socksproxy port 1234. The FloatOuter instances run in the DMZ with dual homed machines with addresses dmzinternal1 and dmzinternal2 as the side exposed to the internal trusted zone. The externally accessible addresses of the DMZ servers are dmzexternal1 and dmzexternal2, which the Internet facing firewall/load balancer maps to banka.com. There is also a zookeeper (must be version 3.5.3-beta) cluster on zookeep1, zookeep2 and zookeep3.

First, the nodes need to be configured in hot-cold mode, with external bridge mode enabled. The nodes will host the P2P Artemis internally, with the journal folder replicated between hot and cold nodes. It is essential that the node registration process be followed on one node and the resulting certificates, keys and network-parameters nodeInfo files are synchronised across the setup. In particular the BridgeInner setup needs a certificates folder containing the sslkeystore.jks and truststore.jks. copied from the node and a copied network-parameters file in the workspace folder. The FloatOuter instances needs a copied network-parameters file only as the public facing SSL is provisioned from the BridgeInner.

In this example the tunnel connection uses local certs which can be generated with Java keytool from the SDK. An example script would be:

keytool.exe -genkeypair -keyalg EC -keysize 256 -alias floatroot -validity 1000 -dname "CN=Float Root,O=Tunnel,L=London,C=GB" -ext bc:ca:true,pathlen:1 -keystore floatca.jks -storepass capass -keypass cakeypass
keytool.exe -genkeypair -keyalg EC -keysize 256 -alias bridgecert -validity 1000 -dname "CN=Bridge Local,O=Tunnel,L=London,C=GB" -ext bc:ca:false -keystore bridge.jks -storepass bridgepass -keypass bridgepass
keytool.exe -genkeypair -keyalg EC -keysize 256 -alias floatcert -validity 1000 -dname "CN=Float Local,O=Tunnel,L=London,C=GB" -ext bc:ca:false -keystore float.jks -storepass floatpass -keypass floatpass

keytool.exe -exportcert -rfc -alias floatroot -keystore floatca.jks -storepass capass -keypass cakeypass > root.pem
keytool.exe -importcert -noprompt -file root.pem -alias root -keystore trust.jks -storepass trustpass

keytool.exe -certreq -alias bridgecert -keystore bridge.jks -storepass bridgepass -keypass bridgepass | keytool.exe -gencert -ext ku:c=dig,keyEncipherment -ext: eku:true=serverAuth,clientAuth -rfc -keystore floatca.jks -alias floatroot -storepass capass -keypass cakeypass > bridge.pem
cat root.pem bridge.pem >> bridgechain.pem
keytool.exe -importcert -noprompt -file bridgechain.pem -alias bridgecert -keystore bridge.jks -storepass bridgepass -keypass bridgepass

keytool.exe -certreq -alias floatcert -keystore float.jks -storepass floatpass -keypass floatpass | keytool.exe -gencert -ext ku:c=dig,keyEncipherment -ext: eku::true=serverAuth,clientAuth -rfc -keystore floatca.jks -alias floatroot -storepass capass -keypass cakeypass > float.pem
cat root.pem float.pem >> floatchain.pem
keytool.exe -importcert -noprompt -file floatchain.pem -alias floatcert -keystore float.jks -storepass floatpass -keypass floatpass

The resulting trust.jks and bridge.jks should be copied to a <workspace>/bridgecerts folder on the BridgeInner instances. The trust.jks and float.jks should be copied to a <workspace>/floatcerts folder on the FloatOuter instances.

Typical configuration for nodeserver1 would be a node.conf files containing:

myLegalName = "O=Bank A,L=London,C=GB"
p2pAddress = "banka.com:10005" // Host and port exposed by Internet facing firewall/load balancer in front of float servers in DMZ.
messagingServerAddress = "nodeserver1:11005" // specifying a different port to the advertised port as an example
messagingServerExternal = false // override default behaviour and ensure that Artemis runs in process.
rpcSettings {
    address = "nodeserver1:10006"
    adminAddress = "nodeserver1:10026"
}
dataSourceProperties { // Point at clustered Azure SQL Server
    dataSourceClassName = "com.microsoft.sqlserver.jdbc.SQLServerDataSource"
    dataSource.url = "jdbc:sqlserver://nodedb.database.windows.net:1433;databaseName=corda;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30"
    dataSource.user = Corda
    dataSource.password = password
}
database {
    transactionIsolationLevel = READ_COMMITTED
    runMigration = false
    schema = dbo
}
security {
    authService {
        dataSource {
            type = INMEMORY
            users = [
                {
                    password = password
                    permissions = [
                        ALL
                    ]
                    username=user
                }
            ]
    }
    }
}
useTestClock = false
enterpriseConfiguration = {
    externalBridge = true // Ensure node doesn't run P2P AMQP bridge, instead delegate to the BridgeInner.
    mutualExclusionConfiguration = { // Enable the protective heartbeat logic so that only one node instance is ever running.
        on = true
        updateInterval = 20000
        waitInterval = 40000
    }
}
compatibilityZoneURL = "http://r3-doorman:10001"
devMode = false // Turn off things like key autogeneration and require proper doorman registration.

Typical configuration for nodeserver2 would be a node.conf files containing:

myLegalName = "O=Bank A,L=London,C=GB"
p2pAddress = "banka.com:10005" // Host and port exposed by Internet facing firewall/load balancer in front of float servers in DMZ.
messagingServerAddress = "nodeserver2:11005" // specifying a different port to the advertised port as an example
messagingServerExternal = false // override default behaviour and ensure that Artemis runs in process.
rpcSettings {
    address = "nodeserver2:10006"
    adminAddress = "nodeserver2:10026"
}
dataSourceProperties { // Point at clustered Azure SQL Server
    dataSourceClassName = "com.microsoft.sqlserver.jdbc.SQLServerDataSource"
    dataSource.url = "jdbc:sqlserver://nodedb.database.windows.net:1433;databaseName=corda;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30"
    dataSource.user = Corda
    dataSource.password = password
}
database {
    transactionIsolationLevel = READ_COMMITTED
    runMigration = false
    schema = dbo
}
security {
    authService {
        dataSource {
            type = INMEMORY
            users = [
                {
                    password = password
                    permissions = [
                        ALL
                    ]
                    username=user
                }
            ]
    }
    }
}
useTestClock = false
enterpriseConfiguration = {
    externalBridge = true // Ensure node doesn't run P2P AMQP bridge, instead delegate to the BridgeInner.
    mutualExclusionConfiguration = { // Enable the protective heartbeat logic so that only one node instance is ever running.
        on = true
        updateInterval = 20000
        waitInterval = 40000
    }
}
compatibilityZoneURL = "http://r3-doorman:10001"
devMode = false // Turn off things like key autogeneration and require proper doorman registration.

Configuration in firewall.conf for bridgeserver1:

firewallMode = BridgeInner // Set the mode the  corda-firewall.jar runs as appropriately.
outboundConfig { // Required section
    artemisBrokerAddress = "nodeserver1:11005" // point at primary Artemis address in the node
    alternateArtemisBrokerAddresses = [ "nodeserver2:11005" ] // List any other HA Artemis addresses
    proxyConfig { // Enable SOCKS proxying by specifying this section
        version = SOCKS5
        proxyAddress = "proxyserver:12345"
        username = "proxyuser"
        password = "password"
    }
}
bridgeInnerConfig { // Required section
    floatAddresses = ["dmzinternal1:12005", "dmzinternal2:12005"] // The BridgeInner initiates a connection to one of this pool of FloatOuter and round-robins
    expectedCertificateSubject = "CN=Float Local,O=Tunnel,L=London,C=GB" // This must align with the certificate subject used by the FloatOuter control.
    tunnelSSLConfiguration { // Use a tunnel specific set of certificates distinct from the node's sslkeystore.jks and truststore.jks.
           keyStorePassword = "bridgepass"
           trustStorePassword = "trustpass"
           sslKeystore = "./bridgecerts/bridge.jks"
           trustStoreFile = "./bridgecerts/trust.jks"
           crlCheckSoftFail = true
    }
}
haConfig { // Enable HA pointing at Zookeeper cluster for master selection.
    haConnectionString = "zk://zookeep1:11105,zk://zookeep2:11105 ,zk://zookeep3:11105"
}
networkParametersPath = network-parameters // The network-parameters file is expected to be copied from the node after registration and here is expected in the workspace folder.

Configuration in firewall.conf for bridgeserver2:

firewallMode = BridgeInner // Set the mode the  corda-firewall.jar runs as appropriately.
outboundConfig { // Required section
    artemisBrokerAddress = "nodeserver2:11005" // point at primary Artemis address in the node
    alternateArtemisBrokerAddresses = [ "nodeserver1:11005" ] // List any other HA Artemis addresses
    proxyConfig { // Enable SOCKS proxying by specifying this section
        version = SOCKS5
        proxyAddress = "proxyserver:12345"
        username = "proxyuser"
        password = "password"
    }
}
bridgeInnerConfig { // Required section
    floatAddresses = ["dmzinternal2:12005", "dmzinternal1:12005"] // The BridgeInner initiates a connection to one of this pool of FloatOuter and round-robins
    expectedCertificateSubject = "CN=Float Local,O=Tunnel,L=London,C=GB" // This must align with the certificate subject used by the FloatOuter control.
    tunnelSSLConfiguration { // Use a tunnel specific set of certificates distinct from the node's sslkeystore.jks and truststore.jks.
           keyStorePassword = "bridgepass"
           trustStorePassword = "trustpass"
           sslKeystore = "./bridgecerts/bridge.jks"
           trustStoreFile = "./bridgecerts/trust.jks"
           crlCheckSoftFail = true
    }
}
haConfig { // Enable HA pointing at Zookeeper cluster for master selection.
    haConnectionString = "zk://zookeep1:11105,zk://zookeep2:11105 ,zk://zookeep3:11105"
}
networkParametersPath = network-parameters // The network-parameters file is expected to be copied from the node after registration and here is expected in the workspace folder.

Configuration in firewall.conf for floatserver1:

firewallMode = FloatOuter // Set the mode the  corda-firewall.jar runs as appropriately.
inboundConfig { // Required section
    listeningAddress = "dmzexternal1:10005" // expose the listening port on the out NIC
}
floatOuterConfig { // Required section
    floatAddress = "dmzinternal1:12005" // await control instructions on inner NIC
    expectedCertificateSubject = "CN=Bridge Local,O=Tunnel,L=London,C=GB" // Must line up with X500 Subject of certificates on BridgeInner
    tunnelSSLConfiguration {
           keyStorePassword = "floatpass"
           trustStorePassword = "trustpass"
           sslKeystore = "./floatcerts/float.jks"
           trustStoreFile = "./floatcerts/trust.jks"
           crlCheckSoftFail = true
    }
}
networkParametersPath = network-parameters // The network-parameters file is expected to be copied from the node after registration and here is expected in the workspace folder.

Configuration in firewall.conf for floatserver2:

firewallMode = FloatOuter // Set the mode the  corda-firewall.jar runs as appropriately.
inboundConfig { // Required section
    listeningAddress = "dmzexternal2:10005" // expose the listening port on the out NIC
}
floatOuterConfig { // Required section
    floatAddress = "dmzinternal2:12005" // await control instructions on inner NIC
    expectedCertificateSubject = "CN=Bridge Local,O=Tunnel,L=London,C=GB" // Must line up with X500 Subject of certificates on BridgeInner
    tunnelSSLConfiguration {
           keyStorePassword = "floatpass"
           trustStorePassword = "trustpass"
           sslKeystore = "./floatcerts/float.jks"
           trustStoreFile = "./floatcerts/trust.jks"
           crlCheckSoftFail = true
    }
}
networkParametersPath = network-parameters // The network-parameters file is expected to be copied from the node after registration and here is expected in the workspace folder.