Conn S NW Acc CTRL Guid

Connectivity
Connectivity to SWIFT
Network Access Control Guide

This network guide explains the SWIFTNet Link-Virtual Private Network and SWIFTNet Link-Hardware Security Module
connections. The document also includes configuration guidelines for network protocols and address management. This
document is for security officers, network administrators, and network designers who design, configure, and manage
SWIFTNet Link-Virtual Private Network and SWIFTNet Link-Hardware Security Module connections for an organisation.
26 June 2015
Table of Contents
.Preface .............................................................................................................................................................................3
1 Introduction ....................................................................................................................................................... 4
2 Configuration Requirements ..................................................................................................................... 5

2.1 Overview of SWIFTNet Network Configuration .................................................................................... 5
2.2 High-level Customer Responsibilities .................................................................................................... 6
2.3 Security Requirements ............................................................................................................................. 7
2.4 Network Requirements ............................................................................................................................. 9
2.5 SWIFTNet Link-Virtual Private Network Configuration ..................................................................... 13
2.6 SWIFTNet Link-Hardware Security Module Connection Examples for LAN-based HSMs ......... 20
2.7 Remote PED Workstation ...................................................................................................................... 22
2.8 Configuring Network Connectivity ........................................................................................................ 23
2.9 Multiple Secure IP Network Access Configurations and Routing .................................................... 24
3 Configuration Guidelines .......................................................................................................................... 29

3.1 SWIFTNet Network Protocols ............................................................................................................... 29
3.2 Domain Name System ........................................................................................................................... 33
3.3 Local Host Names ................................................................................................................................... 33
3.4 Network Address Translation ................................................................................................................ 34
3.5 Configuring Load Sharing for Alliance Connect ................................................................................. 36
.Legal Notices ...............................................................................................................................................................38
2 Network Access Control Guide

Preface
Preface
Purpose of this document
This document assists security officers, network administrators, and network designers to
design, configure, and manage the SWIFTNet Link-VPN and SWIFTNet Link-HSM connections
for their organisations. It also includes configuration guidelines for network protocols and
address management.
Audience
This document is for the following audience:
security officers who want to assess the compliance of the SWIFTNet service network access
requirements with their own security policies
network security administrators who configure network access control devices between their
own network and the SWIFT secure IP network
network designers or network administrators who design solutions that suit the requirements
of SWIFT and of their own organisations
Note During the SWIFTNet implementation process, SWIFT recommends that one of
the intended audience acts as the contact during installation of the
telecommunications equipment.
Significant changes
The table lists the significant changes to this document since the August 2013 edition. This
table does not include editorial changes that SWIFT may have made to improve the usability
and comprehension of the document.
Updated information Location
SWIFTNet Link-HSM requirements "SWIFTNet Link-Hardware Security Module

Requirements" on page 11
Related documentation
The following documents relate to this guide:
Alliance Connect Bronze Service Description
Alliance Connect Bronze Implementation Guide
Alliance Connect Silver Service Description
Alliance Connect Silver Implementation Guide
Alliance Connect Silver Plus Implementation Guide
Alliance Connect Gold Service Description
Alliance Connect Gold Implementation Guide
Browse Configuration Guide
Network Configuration Tables Guide
26 June 2015 3
1 Introduction
SWIFTNet services
SWIFTNet provides secure communication between two parties that are connected to the
SWIFT secure IP network. SWIFTNet consists of InterAct and FileAct messaging services, and
also Browse, a browsing capability that complements the InterAct and FileAct services.
Security policies
Exceptionally, some security policies can impact the end-to-end performance of SWIFTNet. If
you have any questions about the possible performance impact of a SWIFT security policy
proposal, then please contact a SWIFT security representative.
SWIFT has implemented strict security measures, which it has designed to ensure that the
SWIFT network is protected and safe. A SWIFT customer's own security policy can recommend
or mandate the deployment of network access control devices between the customer's network
and SWIFT's network. SWIFT encourages customers to deploy such controls.
Alliance Connect products overview

SWIFT's Alliance Connect products (Bronze, Silver, Silver Plus, Gold) offer the possibility to
connect through the internet or one or two Network Partners who provide and install one or
more managed customer premises equipment and local loops at your premises. For more
information about the Alliance Connect products, see www.swift.com > Products & services >
Connectivity.

Configuration Requirements
2 Configuration Requirements
2.1 Overview of SWIFTNet Network Configuration

Secure IP network access configuration
The diagram "Multi-vendor secure IP network architecture overview" that follows shows the
major network components of the multi-vendor secure IP network, and a possible configuration
for accessing SWIFTNet. The network partners reach the SWIFT backbone network through
their own networks. Network partners provide access ports by means of multiple Points of
Presence (PoPs) that connect to the managed customer premises equipment through local
loops.
The diagram shows a secure IP network access configuration consisting of a managed
customer-premises equipment (known as Alliance Connect Gold) and two permanent lines that
access two separate PoPs supported by separate network partners. Resilience is achieved
through the full redundancy of the network components.
Multi-vendor secure IP network architecture overview
Controlled by
Customer SWIFT Network Partner SWIFT

SWIFTNet Link-VPN
connection
Customer
HSM
network
Local
loops PoP
VPN Network
box Partner 1
HSM router
application secure
PoP
HSM VPN Network IP network
box Partner 2 Backbone
router Network
Customer
network Operating
Managed CPE Centers
application
Network
Partner n
D0650016
Customer premises
26 June 2015 5
Topology
The SWIFTNet Link-VPN connection area of the diagram is the principal consideration when
planning how the customer's network protects SWIFTNet-related traffic.
The equipment that enables access to the SWIFTNet services includes the following elements:
the host machine on which the customer has installed the SWIFTNet Link and Alliance
WebStation software (that is, the SWIFTNet Link host)
network interface cards on the SWIFTNet Link host
the SWIFT managed customer-premises equipment (including VPN boxes, routers, and
cables)
cables to connect the VPN box and the SWIFTNet Link host
cables to connect the HSM box and the SWIFTNet Link host
secure network connections to the SWIFT backbone network
optional customer-managed firewalls

The type of multi-vendor secure IP network Connectivity Pack configuration (such as Alliance
Connect Gold) that the customer selects, determines how these elements are organised.
Note The term SWIFTNet Link host refers to a system that is directly connected to
SWIFTNet, and that runs SWIFTNet Link or Alliance WebStation software. The
SWIFTNet Link host category comprises hosts running Alliance Gateway software
on top of SWIFTNet Link. However, it excludes Alliance WebStations accessing
SWIFTNet indirectly by means of Alliance Gateway, that is, acting as
concentrators.
2.2 High-level Customer Responsibilities

Basic principle
The SWIFTNet design relies on the multi-vendor secure IP network's security and reliability for
the successful exchange of messages between the customer's premises and SWIFT.
VPN and traffic-filtering technology protects the connection between SWIFT and the Virtual
Private Network (VPN) box as part of the managed customer-premises equipment at a
customer site.
To avoid exposing SWIFTNet applications to potential risks, the customer must ensure that it
protects both the SWIFTNet-related traffic and the supporting infrastructure under its control.
The customer must protect the network segment that carries the traffic passing between the
SWIFTNet Link host and the VPN box (the SWIFTNet Link-VPN connection).
When applications are not co-located on the SWIFTNet Link, it is the responsibility of the
customer to protect the network segments between the applications and the SWIFTNet Link.
For guidelines, see "Non Co-located Configurations" on page 14.
Impact of unsecured connections

Although SWIFT encrypts the critical traffic flowing between the SWIFTNet Link host and the
VPN box, end-to-end protection does imply actions from the customer as well.

An unsecured network link (such as a public network) between the SWIFTNet Link host and the
VPN box may expose these systems to a wider community. Such unsecured links can be a
potential source of attack, which would defeat the purpose of the VPN box.
Potential risks
The following undesirable outcomes can occur if the customer does not protect the SWIFTNet
Link-VPN connection appropriately:
Denial of Service attacks on the customer's SWIFTNet Link host, or on the connection to
SWIFT
attacks on traffic integrity, with the intention of data modifications
unauthorised access to the SWIFTNet Link host or the VPN box, with the intention of data
disclosure or modification
2.3 Security Requirements

2.3.1 Securing the SWIFTNet Link-Virtual Private Network
Connection
Protecting against unauthorised use
The customer must ensure that it protects the SWIFTNet Link-VPN connection against any
unauthorised use of the SWIFT services and products. It must also protect against any breach
or any attempted breach of security that can affect the integrity or reliability of the SWIFT
services and products.
To secure the SWIFTNet Link-VPN connection, the customer must do the following:
protect all traffic between the SWIFTNet Link host and the VPN box against packet insertion
or eavesdropping
physically protect the SWIFTNet Link host environment from unauthorised access
protect the SWIFTNet Link host from unauthorised access through the network
physically protect the VPN box environment from unauthorised access
protect the VPN box from unauthorised access through the network
Connecting to another external network

If the customer network hosting a SWIFTNet Link host connects to an external network other
than the secure IP network (for example, the internet or other public network), then the
customer must implement protective measures to safeguard the SWIFTNet Link-VPN
connection. These measures must include installing an appropriately configured filtering device,
such as a firewall.
The use of such a filtering device must not have any negative impact on the configurations
mentioned in the following sections.
26 June 2015 7
Note To benefit from SWIFT's Distributed Denial of Service (DDoS) mitigation solution
available for Internet-facing services, additional firewall configuration is required.
This additional configuration limits the operational impact to your institution in case
SWIFT is subject to a DDoS attack. For additional information, see Knowledge
Base tip 5019964.
2.3.2 Securing the SWIFTNet Link-Hardware Security Module

Connection
LAN-based HSMs
The customer must ensure that it protects the connection between the SWIFTNet Link host and
LAN-based HSMs (the SWIFTNet Link-HSM connection) against any unauthorised use of the
SWIFT services and products. It must also protect against any breach or any attempted breach
of security that can affect the integrity or reliability of the SWIFT services and products.
To secure the SWIFTNet Link-HSM connection, the customer must do the following:
protect all traffic between the SWIFTNet Link host and the HSM box against packet insertion
or eavesdropping
physically protect the HSM box environment from unauthorised access
protect the HSM box from unauthorised access through the network
The customer must ensure that only authorised personnel have physical and logical access to
HSM devices, whether they are actively used or not. HSM devices are HSM boxes, PIN Entry
Devices (PED), and PED keys. The customer must handle spare or backup HSM devices
according to the equivalent security practices that are applied to its live devices.
Clustered HSMs
The customer must adhere to the same security requirements as specified for the SWIFTNet
Link-HSM connection.
USB-based HSMs
USB-based HSMs must either be inserted directly into the USB port of the SWIFTNet Link host
(recommended), or connected to a USB port through a USB extender, USB hub, or USB
Ethernet hub. USB hubs and USB Ethernet hubs must be self-powered USB 2.0 hubs.
USB-based HSMs must not be connected to the SWIFTNet Link host over a wireless
connection. It is the customer's responsibility to protect physically the entire SWIFTNet Link-
HSM configuration. This includes the SWIFTNet Link host, the USB-based HSMs, and its
connection with the SWIFTNet Link host.
HSM tokens or HSM cards, whether they are actively used or not. For example, the customer
must safeguard HSM tokens or HSM cards, whether they are connected to a SWIFTNet Link or
not, when they are not in use, or serve as a backup. Therefore, after an application or a user
has logged off, the customer must remove the HSM token or HSM card and store it in a safe,
secure place. The customer must handle spare or back-up HSM tokens or HSM cards
according to the equivalent security practices that are applied to its live devices.

When using a USB Ethernet hub, the customer must do the following to secure the connection
between the SWIFTNet Link host and the USB Ethernet hub:
Protect all traffic between the SWIFTNet Link host and the USB Ethernet hub against packet
insertion or eavesdropping
Physically protect the network environment from unauthorised access
Protect the USB-based HSM from unauthorised access through the network
Note Unauthorised access to a USB-based HSM can lead to HSM unavailability. For
example, it can lead to HSM lock-out due to multiple failed login attempts.
Remote PED and Remote PED Workstation

the Remote PIN Entry Devices (PED), PED keys, and Remote PED Workstation, whether they
are actively used or not. For example, the customer must safeguard Remote PED devices when
they are not in use or serve as a backup. Therefore, when the Remote PED is not active, the
customer must remove the Remote PED (including PED keys) and store it in a safe, secure
place. The customer must handle spare or backup PED keys according to the equivalent
security practices that are applied to its live devices.
2.4 Network Requirements

2.4.1 SWIFTNet Link-Virtual Private Network Requirements
Important principles
Before the customer configures the network, it must be familiar with the principles in this
section:
The customer must not use the following ranges for the local IP addresses of its SWIFTNet
systems. This includes SWIFTNet Link hosts, VPN boxes, or any network device that
supports secure IP network connectivity.
- 10.0.0.0 through 10.255.255.255
- 149.134.0.0 through 149.134.255.255
- 149.134.173.0 through 149.134.255.255
- 172.16.0.0 through 172.19.255.255
- 172.28.0.0 through 172.28.255.255
- 172.31.0.0 through 172.31.255.255
SWIFTNet uses the following domain: swiftnet.sipn.swift.com

The SWIFTNet domain has a dedicated Domain Name System (DNS). The customer must
ensure that SWIFTNet Link or Alliance WebStation uses the SWIFTNet DNS to resolve
SWIFTNet addresses.
26 June 2015 9
Further guidelines
To enable secure message exchange with SWIFTNet, SWIFT strongly recommends that the
customer adhere to the following principles when planning its network and systems connections:
If the customer configures a filtering device between the SWIFTNet Link host and VPN box,
then the customer must ensure that where TCP session timeout values apply, it sets the
value to at least 60 minutes.
The customer can apply additional Network Address Translation (NAT) as described in
"Network Address Translation" on page 34.
The customer must ensure that SWIFTNet Link or Alliance WebStation always connect by
means of the same managed customer-premises equipment, or set of managed customer-
premises equipment in the case of SWIFTNet Link alternative routing. Alliance Gateway
connects to SWIFTNet using SWIFTNet Link.
The IP addresses assigned to the SWIFTNet Link hosts must be static and must not change
dynamically, for example by Dynamic Host Configuration Protocol (DHCP). These IP
addresses are linked to a specific SWIFTNet Link instance (SWIFTNet Link ID) or Alliance
WebStation instance (SWIFTNet Link-J ID). The IP addresses of the SWIFTNet Link hosts
must not coincide with the IP addresses that the customer has assigned to the VPN boxes or
the NetScreen Redundancy Protocol (NSRP) address (if they are on the same subnet). The
customer must provide these IP addresses to SWIFT, because only the provisioned IP
addresses can connect to SWIFTNet services.
The following information applies only to customers that want to install a SWIFTNet Link or
Alliance Gateway on a UNIX system.
During the GUI-based installation of SWIFTNet Link or Alliance Gateway and its patches, the
firewall must temporarily pass the X11 protocol from the SWIFTNet Link host to the PC (or
other terminal) to enable the Installation GUI to be invoked. This is the firewall between the
SWIFTNet Link host and the PC or terminal (running the X11 server) where the installation is
invoked, and not the firewall between the SWIFTNet Link host and the VPN box. The
customer requires the X11 port (usually limited to 6000/tcp) only when it is installing
SWIFTNet Link or Alliance Gateway. It must close the port after a successful installation.
Silent installation
SWIFT provides the ability to perform a command-line installation based on a 'response' file
prepared in advance for easy execution. This approach allows unattended installations of
multiple instances, avoids manual error, and provides the same tracing features of performed
actions as in the standard graphical installations. Silent installations do not use the X11
protocol, which eliminates the need to open firewall ports. However, silent installations, if not
launched locally on the target system, require a remote connection to the machine running the
installation script.
Single connectivity path

Customers that want to run several applications through the same connectivity path can see the
Connectivity Packs for further details. SWIFT limits by default the number of SWIFTNet Link
hosts that a customer can connect to a single managed customer-premises equipment. This
limit is 30 instances for Alliance Connect.

2.4.2 SWIFTNet Link-Hardware Security Module

Requirements
Important principles for LAN-based HSMs
The customer must adhere to the following principles when planning network connectivity
between SWIFTNet Link and LAN-based HSMs:
The IP addresses assigned to the HSM must be static and not change dynamically, for
example, as a result of DHCP. The IP addresses are linked to a specific HSM box and are
configured at the SWIFTNet Link. SWIFTNet Link uses the configured IP addresses and not
DNS to resolve the IP.
NAT cannot be used between SWIFTNet Link and HSMs.
HSMs can be shared with multiple SWIFTNet Links. A maximum of five SWIFTNet Links can
be connected to an HSM (cluster or stand-alone box).
The customer may connect a maximum of two HSM clusters to a single SWIFTNet link. Each
of these clusters can have a maximum of four HSMs.
Cluster configuration principles

The customer must adhere to the following principles when planning an HSM cluster
configuration:
When configuring HSMs in a cluster to handle HSM failovers, the maximum number of HSMs
in each cluster is limited to four.
All HSMs in the cluster must be connected through the same LAN between SWIFTNet Links
with equivalent network performance.
Important principles for LAN-connected USB-based HSMs

USB-based HSMs may be connected to the SWIFTNet Link host through a USB Ethernet hub.
In such cases, the customer must adhere to the following principles when planning network
connectivity between the SWIFTNet Link host and the USB Ethernet hub:
The IP addresses assigned to the USB Ethernet hub must be static and must not change
dynamically - for example, as a result of DHCP.
NAT cannot be used between the SWIFTNet Link host and the USB Ethernet hub.
Dual Ethernet ports for resilient connectivity

The HSM box has two Ethernet ports. By default, only one of these ports is active and is used to
connect to the network.
However, if the customer wants a more resilient connection between SWIFTNet Links and the
HSM boxes, and between clustered HSM boxes, then the second port can also be activated
and used to connect to the network. The second port must also belong to the same sub-net as
the first port.
The two ports use a single floating IP address, and operate in active/standby mode, with
automatic failover from the active port to the standby port.
Network characteristics
The network characteristics on the path between the SWIFTNet Links and the HSM boxes, and
between clustered HSM boxes, must be those of a high-quality Ethernet Local Area Network.
26 June 2015 11
The performance and reliability of these network paths have a direct impact on the SWIFTNet
main message flow. These network paths must have the following characteristics:
Packet loss
The network paths must be reliable, with less than one packet lost per million. It is strongly
recommended to keep the number of network components on these network paths to a
minimum as they can impact network stability.
Network latency
The network round-trip latency between the SWIFTNet Link and each of its HSM boxes, and
between the HSM boxes in an HSM cluster, must be less than 2 milliseconds, and this
latency must be guaranteed under full load conditions.
For HSM clusters for WebAccess/Browse, round-trip latency between the SWIFTNet Link
and each of its HSM boxes, and between the HSM boxes and in an HSM cluster, may not
exceed 10 milliseconds (for customers with a high number of WebAccess/Browse users, that
is, with more than 250 WebAccess/Browse users) or 20 milliseconds (for customers with a
low number of WebAccess/Browse users, that is, with less than 250 WebAccess/Browse
users). For more information about HSM clusters for WebAccess/Browse, see the Resilience
Guide > SWIFTNet Link-HSM Box Connection.
Note Some firewall configurations between the SWIFTNet Link and the HSM box may
prevent the achievement of this latency target. Customers must design such
configurations carefully. Exceeding this latency target can have a negative
impact on the SWIFTNet Link startup time.
The following are included in the term latency as used here.

The round-trip latency is the sum of the one-way latency from source A to destination B, plus
the one-way latency from B back to A. One-way latency is the time from the start of packet
transmission at the source system to the start of packet reception at the final destination
system. This includes the signal propagation delay over the cables, plus any delay introduced
by intervening network components such as routers, hubs, switches, and firewalls.
The following are excluded from the term one-way latency as used here.
The time between receiving the first bit and the last bit of the packet at the final destination
system, which is a function of the network bandwidth (port speed) at the final destination
system. Also excluded is any application or operating system processing delay at the final
destination system.
Note When determining the delay that an intervening store-and-forward device (router,
switch, firewall, or similar component) can introduce, the packet size is assumed to
be 1500 bytes.
Note Inappropriate use of store-and-forward devices (routers, switches, firewalls, or

similar components) can add significantly to network latency and jitter (variations in
latency).
How to measure this: Doing a ping is a practical, but only an approximate way to measure
round-trip network latency. The following caveats apply when pinging a network:
Ping overestimates the round-trip network latency for the following reasons. It does not
exclude the time to receive the entire ping request packet at the destination system, typically
it does not exclude the time to receive back the ping reply packet at the source system, and it
does not exclude some operating system overheads at both source and destination systems.
All of these must be excluded to get an accurate measurement of round-trip latency. The

amount of overestimating is largely dependent on the network bandwidth (port speed) at the
source and destination systems.
On operating systems supported by SWIFTNet Link (Windows, AIX, Solaris), you must
specify the ping data size as 1458 data bytes to issue a single ping request packet of 1500
bytes.
Ping rounds the measurement down to the lowest millisecond. For example, 2.7 milliseconds
are shown as 2 milliseconds.
With these caveats in mind, here are some rules of thumb to stay within the limit of 2
milliseconds round-trip latency:
If the SWIFTNet Link host's and the HSM box's Ethernet port operate at 10-Mbps port speed,
then a ping from the SWIFTNet Link host with a 1458 data length must return a Round Trip
Time (RTT) of less than or equal to 2 milliseconds.
If the SWIFTNet Link host's and the HSM box's Ethernet port operate at 100-Mbps port
speed, then a ping from the SWIFTNet Link host with a 1458 data length must return a
Round Trip Time (RTT) of less than or equal to 2 milliseconds.
2.5 SWIFTNet Link-Virtual Private Network

Configuration
2.5.1 Co-located Configurations
Controlled and protected customer premises
Co-located configurations are those in which all of the hardware and software that a customer
requires for connectivity to SWIFT reside at a single customer premises.
The simplest configuration to reduce security risks is one in which the customer co-locates the
SWIFTNet Link host and the VPN box within controlled and protected premises.
To help the customer secure the SWIFTNet Link-VPN connection, SWIFT has designed the
recommended configurations presented in this section. Customers can use other co-located
setups, as long as they secure and duly protect the SWIFTNet Link-VPN connection, as
specified in the section "Security Requirements" on page 7.
Multiple SWIFTNet Link hosts, or VPN boxes with a filtering device

A customer connects one or more SWIFTNet Link hosts to one or more VPN boxes through a
LAN that it physically controls and protects on its own premises. The customer has constructed
the LAN to include hubs, switches, bridges, bridging firewalls, and repeaters. This LAN can also
host other applications.
The security of the SWIFTNet Link-VPN connection must conform to the requirements in the
section "Securing the SWIFTNet Link-Virtual Private Network Connection" on page 7.
The customer can usually achieve this security by installing a filtering device, such as a router
with access control lists, or a firewall on the SWIFTNet Link-VPN connection, which can also
carry traffic between the SWIFTNet Link host and the customer network.
26 June 2015 13
Filtering devices on the SWIFTNet Link-VPN connection
Controlled by
Customer SWIFT Network Partner
SWIFTNet Link-VPN connection
Optional Optional dedicated

Ethernet hub, switch, Ethernet hub, switch,
bridge, repeater bridge, repeater Managed CPE
VPN
box
router
Filtering device
Application
D0650008
Customer premises
Alternative multiple SWIFTNet Link hosts or VPN boxes

An alternative is possible to the configuration described in the sub-section Multiple SWIFTNet
Link hosts, or VPN boxes with a filtering device, on page 13if a SWIFTNet Link host is
configured with two network interface cards. In this configuration, one network card is connected
through a direct cable to the VPN box, or through a dedicated hub or switch, to the VPN boxes
or other SWIFTNet Link hosts. The other network card is connected to the customer's network.
In this configuration, the SWIFTNet Link host can take on the role and the location of the
filtering device. Please note, however, that the IP forwarding feature must be disabled on the
SWIFTNet Link host.
2.5.2 Non Co-located Configurations

Compulsory choice between two types of configuration
Non co-located configurations are those in which the SWIFTNet Link and the managed
customer-premises equipment reside at different premises.
A customer can connect the SWIFTNet Link host and the VPN box using connections that are
not under its direct physical control.
If a customer opts for a non co-located configuration, then it must respect the mandatory
configuration requirements that apply to non co-located configurations. This means that a
customer has the option to use either an Alliance Gateway product, or a dedicated and secured
network link. SWIFT does not permit other configurations.

Configuration using Alliance Gateway

Alliance Gateway makes the SWIFTNet Link Application Programming Interface (API) available
to applications that are remote from the SWIFTNet Link host, using a protocol that offers
authentication, integrity, and confidentiality. This supports the connection of remote applications
to a SWIFTNet Link host that the customer has co-located with a VPN box.
Alliance Gateway
Controlled by

Alliance bridge, repeater bridge, repeater Managed CPE
Gateway
VPN
box
router
Filtering device
Secure
remote
connection
Alliance Alliance
Web Platform WebStation Application Application
RA WebSphere MQ
Browse
D0430018
Customer premises
Both the SWIFTNet Link host that runs the Alliance Gateway and the VPN box are co-located,
and the customer can configure them according to one of the options described in "Co-located
Configurations" on page 13.
Configuration using a dedicated and secure remote connection

SWIFT allows the customer to use a remote network link between the SWIFTNet Link host and
the VPN box. However, the customer must ensure that the security of the SWIFTNet Link-VPN
connection conforms to the requirements stated in "Securing the SWIFTNet Link-Virtual Private
Network Connection" on page 7. The customer must also have a mandatory filtering device
between the secure remote connection and the VPN box.
For authentication and encryption of the SWIFTNet Link-VPN connection, SWIFT strongly
recommends a two-way session authentication mechanism.
SWIFT also recommends that:
the customer renews keys associated with the authentication mechanism at least every two
years, and that the customer uses a symmetric key with RSA-based or authenticated Diffie-
Hellman key exchange for traffic encryption
the customer renews encryption keys frequently, typically every other day
26 June 2015 15
For authentication and encryption of the connection between an Alliance WebStation and a
VPN box, the customer does not require any additional configuration.
The customer must be pro-active with Support representatives in managing any problems
related to the connection. The Support representatives may not know of the existence of such a
remote connection or its specifics.
Configuration using a dedicated and secure remote connection
Controlled by

bridge, repeater bridge, repeater Managed CPE
VPN
box
router
Mandatory
filtering device
Secure
remote
connection
Application SWIFTNet Link-VPN connection
D0650009
Customer premises
Exceptions
Any customer that is unable to comply with the mandatory configuration requirements for non
co-located configurations must submit its proposed configuration to SWIFT. SWIFT considers
such a proposed configuration as an exception to the security requirements that apply to the
SWIFTNet Link-VPN connection.
For information about these security requirements, see "Security Requirements" on page 7.
2.5.3 SWIFTNet Link-Virtual Private Network Connection

Examples
Optional connection through an IP router or a firewall
The customer can set up the SWIFTNet Link-VPN connection in any of the following ways:
no routers between the SWIFTNet Link host and the VPN box
using an IP router between the SWIFTNet Link host and the VPN box
using an IP router and a secure, remote connection

The following diagrams illustrate the possible setups.

No routers between the SWIFTNet Link host and the VPN box
Controlled by

Managed CPE
IPSWIFTNet Link 1 IPVPNBox

Subnet 1 Subnet 1 VPN
box
router
Optional SWIFTNet Link-VPN
dedicated Ethernet hub,
switch, bridge, repeater,
bridging firewall
D0650004
Customer premises
An Ethernet LAN connects the VPN box and the SWIFTNet Link host. The Ethernet LAN can
consist only of Ethernet cable or it can include hubs, switches, or repeaters.
If there are no routers between the VPN box and the customer SWIFTNet Link hosts, and only
an Ethernet connection (including any Ethernet cables, hubs, switches, or bridges), then the IP
address assigned to the VPN box and the IP addresses assigned to customer hosts must be on
the same subnet.
Two IP addresses are on the same subnet if they start with the same numbers at the bit level,
and share the same subnet mask. For example, IP addresses 192.168.1.25 and 192.168.1.96
both have subnet mask 255.255.255.0 and are therefore on the same subnet.
Important If there are no routers or firewalls between the SWIFTNet Link host and one or
more VPN boxes, then the VPN box requires that the MAC address of the
SWIFTNet Link host remains the same during a session. This means that if
SWIFTNet Link runs on hardware that allows the use of more than one Ethernet
network interface, for example, a cluster, then the MAC that the customer uses for
communication with SWIFTNet must not change while the SWIFTNet Link is
running. Otherwise the established TCP session or sessions can break.
26 June 2015 17
Using an IP router between the SWIFTNet Link host and the VPN box
Controlled by

Subnet 2 IPGateway IPNext-Hop Subnet 1 Managed CPE
Subnet 2 Subnet 1
VPN
box
router
Optional
filtering device
bridge, repeater bridge, repeater
D0650010
Customer premises
The VPN box and the SWIFTNet Link host connect through at least one IP router or firewall.
When ordering SWIFTNet, the customer must inform SWIFT of the IP address of the next-hop
routing device on the network. This is the device to which the VPN box routes packets sent to
the SWIFTNet Link hosts. The next-hop IP address and the IP address of the managed
customer-premises equipment (VPN box) must be on the same subnet.
If there are routers or similar devices, for example, firewalls or NATting devices, between the
VPN box and the SWIFTNet Link hosts, then the customer must ensure that the IP addresses of
the SWIFTNet Link hosts and the VPN box are on different subnets.
If the customer specifically needs a SWIFTNet Link IP address to be on the same subnet as the
VPN box IP address, while in reality there is at least one router or firewall between the
SWIFTNet Link host and the VPN box, then the customer must enable proxy ARP for the
SWIFTNet Link IP address on the next-hop router or firewall. In this situation, if the customer
does not enable proxy ARP, then communication between the VPN box and the SWIFTNet Link
host may not be possible.
It is possible to have more than one next-hop routing device, in which case each SWIFTNet Link
IP address must correspond to one, and only one, next-hop IP address. The VPN box contains
a static route for each SWIFTNet Link IP address, which points to the next-hop IP address.
If the customer wants a high-availability setup, in which another customer router or firewall takes
over if the designated next-hop router or firewall fails, then that other router must keep the same
IP address when the failover occurs. The customer must implement a clustering or high-
availability technique such as HSRP, VRRP, or NSRP. For an explanation of the dual firewall
configuration, see "Configuring Network Connectivity" on page 23.
Note Since the next-hop IP address is often a firewall, it is sometimes called the firewall
IP address.

Important The VPN box (or boxes) requires that the MAC address of the next-hop firewall or
the router remains the same during a TCP session. This means that if the customer
has clustered the firewall or router, or runs it in a high-availability mode, then the
MAC address must not change in the event of a failover. Otherwise the established
TCP session (or sessions) can break.
If an IP router or a firewall protects the SWIFTNet Link host, then the customer
must do one of the following:
Locate the SWIFTNet Link host on a different IP subnet to the VPN box, which
means that the IP router or the firewall is the next-hop IP address and must
respond to Address Resolution Protocol (ARP) requests.
Locate the SWIFTNet Link host on the same subnet as the VPN box. In this
case, the IP router or firewall must perform proxy ARP.
Using an IP router and a secure remote connection
Controlled by

Managed CPE
Subnet 2 IPGateway IPNext-Hop Subnet 1
Subnet 2 Subnet 1
Secure VPN
remote box
connection
Gateway Next hop
router
firewall/router firewall/router

bridge, repeater bridge, repeater
D0650005
Customer premises
SWIFTNet Link Alternative Routing

For SWIFTNet Link Alternative Routing, the customer must configure two SWIFTNet Link-VPN
connections. These connections can be a combination of any of the three configurations
described earlier in this section.
For more information about SWIFTNet Link Alternative Routing, see the Connectivity Packs.
The customer must ensure that all SWIFTNet-related IP traffic is routed towards the same
managed customer-premises equipment once the SWIFTNet Link subsystem is started. Only in
the event of a failure of that connection can the SWIFTNet-related IP traffic from the SWIFTNet
Link host be redirected to the other managed customer-premises equipment. In this event, the
SWIFTNet Link subsystem must also be restarted.
26 June 2015 19
2.6 SWIFTNet Link-Hardware Security Module

Connection Examples for LAN-based HSMs
Cluster configuration
HSM boxes support a High Availability cluster setup. A maximum of two clusters, each
composed of from two to four HSM boxes, can be connected to the SWIFTNet Link. Customers
can deploy the clusters in a network topology that adheres to the network and security
requirements described in this document.
Controlled by Customer
HSM Cluster 1 HSM Cluster 2
Dedicated LAN
To VPN
D0650023
SWIFTNet Link host
Dedicated LAN configuration

The customer connects one or more HSM boxes in a dedicated LAN and enables connectivity
of the SWIFTNet Link host using a separate interface card connecting to the HSM LAN. In this
configuration, it is possible to share HSMs by using multiple SWIFTNet Link hosts.
The SWIFTNet Link-HSM connection must conform to the security requirements described in
"Securing the SWIFTNet Link-Hardware Security Module Connection" on page 8. The customer
may use filter devices on the SWIFTNet Link-HSM connection, but such configurations must
conform to the requirements described in "SWIFTNet Link-Hardware Security Module
Requirements" on page 11.
HSM box 1 HSM box 2
Dedicated LAN
To VPN
D0650020
SWIFTNet Link host

Demilitarised Zone LAN configuration

The customer connects one or more HSM boxes to the same LAN as the SWIFTNet Link hosts.
It is possible to share HSMs across multiple SWIFTNet Link hosts residing on the same LAN.
The SWIFTNet Link-HSM connection must conform to the security requirements described in
"Securing the SWIFTNet Link-Hardware Security Module Connection" on page 8. No
connectivity is required between the HSM boxes and the VPN. If a filtering device is used on the
SWIFTNet Link-VPN network, then the configuration must not allow any communication
between the HSM and the VPN.
SWIFTNet Link host
HSM box 1 HSM box 2
DMZ LAN
To VPN
D0650021
Back-office LAN configuration
A customer connects one or more HSM boxes to the customer network, away from the
Demilitarised Zone (DMZ) network. This configuration is acceptable as long as all the security
and network requirements specified in this document are met. It is very important, however, that
the access to the HSMs is restricted to SWIFTNet Link-HSM traffic only. If an optional filtering
device is placed on the SWIFTNet Link-Application network, then the configuration must allow
SWIFTNet Link-HSM connectivity.
Back-office LAN
SWIFTNet Link host
To VPN
HSM box 1
HSM box 2
D0650022
26 June 2015 21
2.7 Remote PED Workstation

Overview
This section applies only if a customer has installed the HSM box Remote PIN Entry Device
(PED) at a Remote PED Workstation. It provides guidelines to connect the Remote PED
Workstation and the SWIFTNet Link host.
Remote PED Workstation

SWIFTNet customers who choose to use the Remote PIN Entry Device (PED) for HSM box
management require a host computer (Windows platform) to which a Remote PED is physically
connected over USB. In this document, such a computer is referred to as the Remote PED
Workstation.
Connecting the Remote PED Workstation and the SWIFTNet Link host
In the diagram "Remote PED Workstation to SWIFTNet Link host connection" on page 22, the
SWIFTNet Link host connects to a Remote PIN Entry Device (PED) Workstation over the
customer network. The SWIFTNet Link host communicates with HSM boxes over the SWIFTNet
Link-HSM connection. For details about how to configure the SWIFTNet Link-HSM connection,
see "SWIFTNet Link-Hardware Security Module Connection Examples for LAN-based HSMs"
on page 20.
Remote PED Workstation to SWIFTNet Link host connection
Customer HSM
Remote PED network
Workstations
HSM
HSM
Customer
network
D0170017
Optional
filtering device
The customer can install an optional filtering device, such as a firewall, internal to the institution,
between the Remote PED Workstations and the SWIFTNet Link host, thereby restricting access
to the SWIFTNet Link host from the customer network.
For more information about how to configure this filtering device, see the Remote PED
Workstation and Firewalls section in the Network Configuration Tables Guide.

Network latency
The network round-trip latency between the SWIFTNet Link host and the Remote PIN Entry
Device (PED) Workstation should not exceed 500 milliseconds. Exceeding this latency target
could negatively impact the operation of the Remote PED.
Note Inappropriate use of certain network components such as routers, hubs, switches,
and firewalls can add significantly to network latency.
2.8 Configuring Network Connectivity

SWIFTNet configuration
If a customer has a pair of VPN boxes in an active/standby setup, then the customer must do
the following:
Route to the NetScreen Redundancy Protocol (NSRP) IP address (the virtual IP address
shared by the two devices). The active VPN box claims the NSRP IP address as its own.
Limit to seven the network connectivity configurations on a single Ethernet LAN or VLAN.
The VPN boxes are NetScreen devices. If a customer intends to use other NetScreen devices
with NetScreen's NSRP protocol on the customer Ethernet network to which it has connected
the VPN boxes, then the following information is relevant.
Each Alliance Connect solution has a virtual Ethernet (MAC) address from the following list:
00:10:db:ff:20:d1
00:10:db:ff:40:d1
00:10:db:ff:60:d1
00:10:db:ff:80:d1
00:10:db:ff:a0:d1
00:10:db:ff:c0:d1
00:10:db:ff:e0:d1
Customers must ensure that no other NetScreen or Juniper equipment, which is connected to
the Ethernet network to which a network connectivity configuration is also connected, uses a
MAC address from the preceding list. This is to avoid a potential conflict with the virtual MAC
address of the connectivity configuration.
Failover for network connectivity configurations

In the event of failure of the active VPN box, the second VPN box takes over the virtual NSRP
IP address of the managed customer-premises equipment. It also takes over the virtual media
access (MAC) address. This is announced by means of a gratuitous Address Resolution
Protocol (ARP) broadcast. For correct takeover or recovery, it is essential that this broadcast
reaches all Ethernet equipment, for example, self-learning Ethernet switches, for which the
change in the physical route to that virtual MAC address is significant.
26 June 2015 23
Dual firewall configuration

If a customer uses a dual firewall configuration (on the path) between the SWIFTNet Link host
and VPN boxes, then the second firewall must support stateful failover. That is, the standby
firewall must take over the session table of the failing firewall.
It is important that the MAC address of the next-hop firewall that the customer uses for
communication with the VPN box remains the same throughout the session. This means that
this MAC address must not change in the event of a failover. Otherwise, the established TCP
session or sessions can break.
2.9 Multiple Secure IP Network Access

Configurations and Routing
Secure IP network access configurations
This section identifies issues, and provides possible solutions for customers that want to
transport SWIFTNet traffic from multiple SWIFTNet Link hosts across multiple secure IP
network access configurations.
A secure IP network access configuration consists of two VPN boxes. Both boxes share a
single, virtual IP address (see "Configuring Network Connectivity" on page 23). For the
purposes of routing, they can be seen as a single device.
For more information, Alliance Connect new network connectivity solutions on page 4 in
"Introduction" on page 4
If a customer has multiple secure IP network access configurations, then it must decide with
which of these secure IP network access configurations it will associate the IP address of the
SWIFTNet Link host. The customer makes this decision during the SWIFTNet Ordering process.
SWIFTNet routing ensures that traffic from SWIFTNet for a particular SWIFTNet Link host IP
address is always delivered by means of that same secure IP network access configuration.
The customer must configure the routing of the SWIFTNet Link-VPN connection to ensure the
following traffic conditions:
that traffic from a particular SWIFTNet Link host IP address to SWIFTNet is always routed to
the same secure IP network access configuration as selected by the customer during the
SWIFTNet Ordering process
that traffic to a particular SWIFTNet Link host IP address from SWIFTNet is routed from this
secure IP network access configuration to the correct SWIFTNet Link host
Routing device configuration

Customers may experience technical difficulties if traffic that is destined for different secure IP
network access configurations is mixed together on one of the customer's routing devices.
Since a routing device usually looks only at the destination addresses of the IP packets, it is not
able to decide through which secure IP network access configuration it must send the data to
reach SWIFT's SWIFTNet servers.
The remainder of this section offers some suggestions for overcoming this problem.

No sharing of routing devices

In this case, there is one router or firewall for each secure IP network access configuration. The
SWIFTNet Link hosts must send SWIFTNet-destined traffic through the appropriate router or
firewall IP address, see the figure at "Multiple routers/firewalls: one for each secure IP network
access configuration". The customer must configure each router or firewall with the correct
routing table to forward all traffic destined for SWIFTNet through the appropriate secure IP
network access configuration. Conversely, the customer configures the secure IP network
access configuration with a static route for traffic for a given SWIFTNet Link host IP address to
the appropriate router or firewall. This is simple to set up and easy to troubleshoot. It does not
require routing decisions based on the source IP address, otherwise known as policy-based
routing.
Multiple routers/firewalls: one for each secure IP network access configuration
Controlled by
Customer SWIFT
SWIFTNet Link-VPN
connection
192.168.1.1/24
VPN
1 2.1.2.1/24 2.1.2.200/24 192.168.1.200/24 box
Filtering
device A
192.168.2.1/24 VPN
2 box
2.2.2.1/24 2.2.2.200/24 192.168.2.200/24
Filtering
device B
D0650013
Customer premises
In this example, the routing table entries are as follows:
SNL1
Destination 149.134.0.0 netmask 255.255.0.0 gateway 2.1.2.200
SNL2
Filtering device A
Filtering device B
26 June 2015 25
Sharing at least one routing device

All SWIFTNet Link hosts send SWIFTNet-destined traffic to the same router or firewall, or at
least one routing device routes SWIFTNet traffic for different secure IP network access
configurations. The next-hop router or firewall, that is, the router or firewall located nearest to
the VPN boxes, must route traffic from each SWIFTNet Link host IP address to its associated
secure IP network access configuration, see "SWIFTNet Link-Virtual Private Network
Connection Examples" on page 16. The customer must therefore base its routing decision on
the source IP addresses of the SWIFTNet Link host.
Unfortunately, few firewalls can redirect based on source IP addresses. If this is the case, then
one solution is to put an additional router between the firewall and the secure IP network access
configurations, and let that router route the IP packets based on source IP addresses, see the
diagram "Routing of IP packets based on the source IP addresses". This can be done on
routers that support policy-based routing.
Routing of IP packets based on the source IP addresses
Controlled by
Customer SWIFT
SWIFTNet Link-VPN
connection
3.3.1.1/24 3.3.3.1/24 VPN

1 192.168.3.201/24
box
3.3.1.201/24
3.3.3.200/24
192.168.3.200/24
Filtering Next-hop VPN
device router box
2 3.3.1.2/24 3.3.3.2/24
D00650012
Customer premises
In this example, the routing table entries are as follows:
SNL1
SNL2
Filtering device
Next-hop router
Source 3.3.1.1-Destination 149.134.0.0 netmask 255.255.0.0 gateway 3.3.3.1
Source 3.3.1.2-Destination 149.134.0.0 netmask 255.255.0.0 gateway 3.3.3.2

Routing traffic to the multi-vendor secure IP network and swift.com

SWIFT uses the 149.134.0.0/16 network on both the multi-vendor secure IP network and
swift.com to host various SWIFTNet and internet-facing services. Therefore, customers must
configure their internal routing as follows:
route traffic destined for multi-vendor secure IP network to the VPN boxes
route traffic destined for swift.com to their internet gateway

A customer must also configure their name resolution to resolve SWIFTNet addresses through
multi-vendor secure IP network and swift.com addresses over the internet. SWIFT provides the
following recommendations regarding this routing and name resolution:
Segregated environments
Customers should use segregated environments where possible. An environment using
multi-vendor secure IP network (for example, a SWIFTNet Link and all network equipment
leading up to the VPN pack) should route all traffic to destination network 149.134.0.0/16 to
the VPN pack. An environment using swift.com (for example, network equipment supporting
an end-user's workstation) should allow all traffic to destination network 149.134.0.0/16 to be
routed to their internet gateway.
Mixed environments
Customers may use a mixed environment where network equipment supports traffic destined
for both multi-vendor secure IP network and swift.com (for example, the local network
supports SWIFTNet Link hosts and end-user workstations).
Customers using a mixed environment must:
decide which host uses which environment (multi-vendor secure IP network or internet)
configure name resolvers in their hosts according to the environment
route traffic to destination network 149.134.0.0/16 to the VPN boxes
add more specific routes to the following networks for SWIFT services reachable over the
internet:
149.134.144.0/24
149.134.145.0/24
149.134.146.0/24
149.134.148.0/24
149.134.152.0/24
149.134.156.0/24
149.134.157.0/24
149.134.158.0/24
149.134.168.0/24
149.134.169.0/24
149.134.170.0/24
149.134.176.0/24
26 June 2015 27
149.134.177.0/24

Configuration Guidelines
3 Configuration Guidelines
3.1 SWIFTNet Network Protocols

General information for SWIFTNet network protocols
This section lists the network protocols that the SWIFTNet service requires, and includes a short
description of each protocol and its purpose in the SWIFTNet context. The table, "SWIFTNet
network protocol information", gives an overview of protocol information. See the Network
Configuration Tables Guide for details about the IP port access that SWIFTNet requires if it is to
function correctly.
SWIFTNet network protocol information
Protocol Description Purpose
Tuxedo(1) Oracle Tuxedo - a proprietary Transport used for core message

middleware transport exchange by means of SWIFTNet
IIOP(2) Internet Inter ORB - an Object Transport used for core message
Management Group (OMG) exchange from Alliance
industry standard WebStations by means of
SWIFTNet
DNS Domain Name System Transfer:
SWIFT.Name Server records to

SWIFTNet client
IP Domain Name to IP Address

resolution
LDAP Lightweight Directory Access Retrieve:

Protocol
Information about SWIFTNet
clients
Security certificates
HTTP HyperText Transport Protocol - Used to retrieve SWIFT Certificate

Web access Authority certificates
HTTPS HyperText Transport Protocol HTTPS provides access to:

Secure - Web access, HTTP
Secure SWIFTNet Link
Browse access secured by

means of Secure Sockets Layer
(SSL)
Secure Channel server
Generate and retrieve Secure

Sockets Layer (SSL) web
certificates
26 June 2015 29
Protocol Description Purpose
PKIX-CMP Internet X.509 Public Key Creation and renewal of SWIFTNet

Infrastructure Certificate client PKI profile
Management Protocol (PKIX-CMP)
according to Internet RFC 2510
(1) Customers need use the Tuxedo protocol only for SWIFTNet Link. Alliance WebStation does not require it.
(2) Customers need use the IIOP protocol only to connect Alliance WebStation directly to SWIFTNet. It is not
necessary to use it for SWIFTNet Link or for an Alliance WebStation connected to an Alliance Gateway.
Network access control policy

The Network Configuration Tables Guide describes the systems, IP addresses, protocols, and
ports that the customer requires to configure its network access control device (router or
firewall) to support the SWIFTNet services.
Customers can base the network access controls that they require for their security policies on
the information in the Network Configuration Tables Guide. Such policies commonly include the
following traffic restrictions:
The customer only permits return traffic on ports greater than 1023, and only when part of an
established TCP connection.
UDP-based DNS traffic must be inspected, in order that return traffic into the customer
network is permitted only as a response to a previous outgoing request.
A stateful firewall that has a firewall filter policy aligned with the information in the Network
Configuration Tables Guide meets the requirements of such a policy.
Alliance Gateway and firewalls

In the diagram "Installation with two firewalls", the Alliance Gateway is the concentrator of the
Alliance WebStation, the Alliance Web Platform, and other applications that the customer runs
with either the Remote API or WebSphere MQ. The Alliance Gateway connects to the secure IP
network through a SWIFTNet Link instance.
Alliance Gateway can also accept Simple Object Access Protocol (SOAP) messages using the
Web Service Host Adapter. In that case, Alliance Gateway can send messages either over
SWIFTNet only, or partially over SWIFTNet and over the multi-vendor secure IP network.
In a situation where the business messages are sent with HTTPS over the multi-vendor secure
IP network, an ad-hoc configuration is required.

Installation with two firewalls
Controlled by
Alliance
Web Platform
SWIFT
WebAccess
Alliance
WebStation
SWIFTNet Link-VPN
connection Managed CPE
Application
VPN permanent Network
RA box connection
router PoP Partner 1
Alliance
Gateway
Application Customer
network
WebSphere MQ
FW2 FW1 VPN permanent Network
connection Partner 1
box or 2
router PoP
One-time DMZ
password LDAP
Authentication
Server
Simple Network
Management
Protocol Manager
D0430004
Customer premises
The customer installs a SWIFTNet Link-to-secure IP network firewall, FW1 in the diagram,
between the SWIFTNet Link and the secure IP network. It installs another concentrator firewall,
internal to the Institution, FW2 in the diagram, between the applications and the Alliance
Gateway. This makes it possible for the customer to place the Alliance Gateway in a DMZ.
For more information about how to configure the firewall installation, see the Alliance Gateway
and Firewalls section in the Network Configuration Tables Guide.
Note The diagram "Installation with two firewalls" illustrates firewalls in a logical way.
The customer can achieve the configuration by using a single firewall with at least
three Ethernet interfaces.
Note Customers must open all ports that relate to Alliance Gateway on the firewall, FW2
in the diagram "Installation with two firewalls". The Network Configuration Tables
Guide provides more information about these ports.
26 June 2015 31
Browse configuration
When Alliance WebStation or Alliance Web Platform is used with Alliance Gateway, the HTTPS
traffic optionally goes through an HTTP proxy. Alternatively, NAT devices can be used to route
the HTTPS traffic to SWIFTNet. For more details, see the Browse Configuration Guide. If an
HTTP proxy is used, then this proxy can reside either on the Alliance Gateway host machine or
on another host machine. Considering the various integration perspectives and security
guidelines that may be applicable to your environment, it is generally advisable to run the HTTP
proxy on a host machine that is different from the host machine on which Alliance Gateway is
running. This is described in the Browse Configuration Guide.
The diagram, provides an overview of the configuration.
Alliance WebStation or
Alliance Web Platform
FW2 Typically,
Port 48002, 48003 port 80 or 8080
Alliance Gateway HTTP Proxy

/SWIFTNet Link host
host
IP2
IP1
Natting: IP1 --> IP3

IP2 --> IP3
FW1 IP3
SWIFTNet HTTPS flow
D0650017
InterAct/FileAct
This configuration requires hide NAT for the outbound connections.

In this configuration, the customer must use NAT to translate the IP address of the SWIFTNet
Link (IP1) and the IP address of the HTTP proxy (IP2) to the SWIFTNet Link host IP address
that was communicated to SWIFT during the SWIFTNet ordering process (IP3).
The customer must translate the source IP address of packets sent to SWIFT by Alliance
Gateway (IP1) and the HTTP proxy (IP2) into the IP address it communicated to SWIFT as
being its SWIFTNet Link host IP (IP3). The customer must secure the HTTP proxy-VPN
connection in the same manner as the SWIFTNet Link-VPN connection.
For the SWIFTNet Link-to-secure IP network firewall (FW1), the filtering policy between the
Alliance Gateway/SWIFTNet Link host (IP3) and the secure IP network remains as explained in
the Network Configuration Tables Guide. The filtering policy between the HTTP proxy host and
the secure IP network requires an additional rule, as documented in the Browse Members
section of the Network Configuration Tables Guide.
The filtering policy of the firewall (FW2) between the Alliance WebStation or Alliance Web
Platform and the HTTP proxy must allow Browse sessions. The exact port number that is

permitted, typically 80/tcp or 8080, depends on the configuration of the HTTP proxy. For more
information about configuring the HTTP proxy, see the Browse Configuration Guide.
Note For more information about ports 48002 and 48003, see the Network Configuration
Tables Guide.
3.2 Domain Name System

Configuration
For information about configuring the Domain Name System (DNS), see the SWIFTNet Link
Installation Guide.
Additionally, see individual product documentation for specific DNS configuration requirements.
3.3 Local Host Names

Resolving local host names
Customers can resolve local host names on the SWIFTNet Link host or Alliance WebStation in
the following ways:
a zone-forwarding DNS server
a shared, zone-forwarding DNS server
A zone-forwarding DNS server

SWIFT recommends that the customer run a forwarding DNS server on each SWIFTNet Link
host. The customer must configure this forwarding DNS server to have no local data, to look up
the SWIFTNet DNS for names in the domain swiftnet.sipn.swift.com, and to look up a corporate
DNS server for any other name.
The customer must ensure that the DNS server is only accessible from the particular SWIFTNet
Link host it runs on. This is to avoid requests to the SWIFTNet DNS from any other machine.
A shared, zone-forwarding DNS server

A shared, zone-forwarding DNS server is a variant of the previous solution, whereby various
SWIFTNet Link hosts do not have their own forwarding DNS server, but all use a single DNS
server, or two, for resilience.
The customer must ensure that this DNS server runs on a machine that SWIFT knows as a
SWIFTNet Link host, otherwise the DNS requests to SWIFTNet are blocked. Customers must
restrict access to this DNS to the specific SWIFTNet Link hosts, and they must disable caching.
Important In this setup, the DNS server may become a single point of failure if it is not as
resilient as the various SWIFTNet Link hosts.
26 June 2015 33
3.4 Network Address Translation

Managed customer-premises equipment performs Network Address Translation
The managed customer-premises equipment performs NAT to map the internal IP addresses of
SWIFTNet Link hosts, or of systems hosting a Web server, to SWIFT IP addresses.
The customer must give to SWIFT the internal addresses of SWIFTNet Link hosts, or of
systems hosting a Web server, in order that SWIFT can assign SWIFT addresses to them and
can configure the managed customer-premises equipment to perform the necessary translation.
The SWIFTNet Link software located at the customer site accesses SWIFT IP addresses that
correspond to the SWIFTNet Network servers. These addresses are specified in the Network
Configuration Tables Guide. The managed customer-premises equipment does not modify
these addresses.
SWIFT does not hide SWIFTNet server addresses on the managed customer-premises
equipment, as this can produce a heavy administrative overhead and can cause errors.
Currently, SWIFT asks customers ordering SWIFTNet to specify the local IP address of the
SWIFTNet Link host.
Note Web Server and SWIFTNet Link cannot be defined with the same IP address on
SWIFTNet. If the institution builds multiple Web servers, then each one must have
its own IP address.
Customer-defined NAT
A customer's internal security policy may call for an additional NAT if the organisation wants to
hide the following information:
internal IP addresses to SWIFT
SWIFT IP addresses on the customer network.

The customer can install the NAT on either a filtering router or a firewall located between the
managed customer-premises equipment and the customer internal network.
Hiding customer internal IP addresses

An additional NAT makes the customer organisation independent of SWIFT, so that if the
organisation wants to revise its IP addressing scheme it can do so by reconfiguring the NAT
device.
If the customer organisation does not want to communicate its internal IP addresses to SWIFT,
then it can use the NAT device to map the internal addresses to new IP addresses. The
customer can communicate the new addresses to SWIFT instead of the real internal addresses.
The diagram "Mapping using a NAT device" on page 35 illustrates this configuration.

Mapping using a NAT device
Controlled by
SNL-VPN
connection
NAT device M-CPE

Customer VPN
network box router
Source Destination
a.b.c.d 149.134.x.y
NAT
w.x.y.z 149.134.x.y
D0170012
Customer premises
In this example, the NAT device maps the source address of the IP packet sent to SWIFT from
a.b.c.d (true address) to w.x.y.z (dummy address), and conversely for the destination address of
packets received from SWIFT.
Hiding SWIFT's IP addresses
Translating addresses in DNS responses using a NAT device
Controlled by
SWIFTNet Link-VPN
connection
NAT device Managed CPE
Customer
VPN
network
box router
Source Destination
SWIFTNet Link e.f.g.h
NAT
SWIFTNet Link 149.134.x.y
D0170013
Customer premises
In this example, the NAT device maps the destination address of the IP packet sent to SWIFT
from e.f.g.h to 149.134.x.y, and conversely for the source address of packets received from
SWIFT.
The SWIFT IP address that is used during SWIFTNet Link installation, such as the SWIFTNet
DNS address, is replaced by an internal address that the customer has selected.
26 June 2015 35
The customer can use an additional NAT device to impact firewall configuration. If the customer
locates the NAT device on the internal side of the firewall, then the device filters on the basis of
the addresses known to SWIFT.
These addresses include the following:
the SWIFTNet Link host IP address that the customer has communicated to SWIFT
SWIFT server addresses as specified in this document and identified in the Network
Configuration Tables Guide
If the customer locates the NAT device on the external side of the firewall, then the device filters
on the basis of the addresses that the customer has resolved using the NAT.
However, in this case the NAT device must also translate the addresses in the DNS replies that
SWIFT returns. When the SWIFTNet DNS returns an address, it must be converted to the
corresponding address used on the customer network, see the diagram "Translating addresses
in DNS responses using a NAT device" on page 35.
3.5 Configuring Load Sharing for Alliance Connect

Principle
By default, all InterAct, FileAct, and Browse traffic is sent through the primary VPN box (box A),
router and leased line. In case of failure of one of these connectivity components, all the traffic
is automatically switched over to the secondary line.
The load sharing option allows you to send InterAct or FileAct traffic (or both) through the
secondary VPN box (box B) and back-up line for all SWIFTNet Link hosts or a subset.
Enabling load sharing does not impact fail-over mechanisms. In case of failure of one of the
lines or equipment, VPN box or router, all traffic is automatically switched over to the remaining
line, regardless of any load sharing setup.
The return traffic from SWIFT to the customer premises follows the same path taken by the
initial outgoing traffic session. Since only instances of SWIFTNet Link can establish sessions,
the routing of the return traffic over the primary or secondary link takes the same path as the
outgoing traffic.
Supported configurations
The following configurations are supported:
No load-sharing (default configuration)
Browse traffic on the primary line and InterAct/FileAct traffic on the secondary line for all
instances of SWIFTNet Link.
Browse traffic on the primary line and InterAct/FileAct traffic on the secondary line for a
subset of SWIFTNet Link instances.
If some SWIFTNet Link instances are reserved for InterAct traffic only, then this
configuration can be used to redirect InterAct traffic to the secondary line, while the traffic
from other SWIFTNet Link instances and Browse traffic are routed through the primary
line.
With SWIFTNet 7.0, SWIFT provides additional segregation capability to channel InterAct traffic
and FileAct traffic separately over the lines of an Alliance Connect connectivity product. This will
allow customers to channel for example Browse and InterAct traffic over one line, and FileAct

traffic over the other. Alternatively, it allows to channel Browse and FileAct over one line, and
InterAct over the other. Customers can configure this setup by a new SWIFTNet Link command.
Note In this context, FIN traffic follows the same path as InterAct traffic. For more
information, see the SWIFTNet Link Operations Guide.
Practical configuration
The customer sends InterAct and FileAct traffic to SWIFT IP addresses. To refer to these IP
addresses, see the Network Configuration Tables Guide. Customers that want to send the
InterAct and FileAct traffic through the secondary line must establish a rule in their firewall that
offsets destination ports according to the following table.
Offset destination ports
TCP ports without load sharing Offset value TCP ports offset for load
sharing
50153-50190 -30000 => 20153-20190
50200-50806 -30000 => 20200-20806
52100-52399 -30000 => 22100-22399
Limitations
Browse traffic cannot be shared over the secondary line, and is always sent over the primary
VPN box (box A) and leased line. Upon failure of the primary line, Browse traffic uses the
secondary VPN box and leased line.
26 June 2015 37
Legal Notices
Copyright
SWIFT 2015. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly grants
you that right, in which case ensure you comply with any other applicable conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT
logo, SWIFT, SWIFTNet, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and
SWIFT Institute. Other product, service, or company names in this publication are trade names, trademarks,
or registered trademarks of their respective owners.

Conn S NW Acc CTRL Guid

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Conn S NW Acc CTRL Guid

Încărcat de

Drepturi de autor:

Formate disponibile

Connectivity

Network Access Control Guide

2 Configuration Requirements ..................................................................................................................... 5

3 Configuration Guidelines .......................................................................................................................... 29

2 Network Access Control Guide

Updated information Location

SWIFTNet Link-HSM requirements "SWIFTNet Link-Hardware Security Module

Alliance Connect Bronze Service Description

Alliance Connect Bronze Implementation Guide

Alliance Connect Silver Service Description

Alliance Connect Silver Implementation Guide

Alliance Connect Silver Plus Implementation Guide

Alliance Connect Gold Service Description

Alliance Connect Gold Implementation Guide

Browse Configuration Guide

Network Configuration Tables Guide

Alliance Connect products overview

4 Network Access Control Guide

2.1 Overview of SWIFTNet Network Configuration

Multi-vendor secure IP network architecture overview

Customer SWIFT Network Partner SWIFT

network interface cards on the SWIFTNet Link host

secure network connections to the SWIFT backbone network

optional customer-managed firewalls

2.2 High-level Customer Responsibilities

Impact of unsecured connections

6 Network Access Control Guide

attacks on traffic integrity, with the intention of data modifications

2.3 Security Requirements

physically protect the VPN box environment from unauthorised access

Connecting to another external network

2.3.2 Securing the SWIFTNet Link-Hardware Security Module

physically protect the HSM box environment from unauthorised access

8 Network Access Control Guide

Physically protect the network environment from unauthorised access

Remote PED and Remote PED Workstation

2.4 Network Requirements

SWIFTNet uses the following domain: swiftnet.sipn.swift.com

Single connectivity path

10 Network Access Control Guide

2.4.2 SWIFTNet Link-Hardware Security Module

NAT cannot be used between SWIFTNet Link and HSMs.

Cluster configuration principles

Important principles for LAN-connected USB-based HSMs

Dual Ethernet ports for resilient connectivity

The following are included in the term latency as used here.

Note Inappropriate use of store-and-forward devices (routers, switches, firewalls, or

12 Network Access Control Guide

2.5 SWIFTNet Link-Virtual Private Network

Multiple SWIFTNet Link hosts, or VPN boxes with a filtering device

Filtering devices on the SWIFTNet Link-VPN connection

Customer SWIFT Network Partner

SWIFTNet Link-VPN connection

Optional Optional dedicated

Alternative multiple SWIFTNet Link hosts or VPN boxes

2.5.2 Non Co-located Configurations

14 Network Access Control Guide

Configuration using Alliance Gateway

Customer SWIFT Network Partner

SWIFTNet Link-VPN connection

Optional Optional dedicated

Configuration using a dedicated and secure remote connection

Configuration using a dedicated and secure remote connection