IPsec Site-to-Site VPN Example with Pre-Shared Keys

A site-to-site IPsec tunnel interconnects two networks as if they were directly
connected by a router. Systems at Site A can reach servers or other systems at
Site B, and vice versa. This traffic may also be regulated via firewall rules,
as with any other network interface. If more than one client will be connecting
to another site from the same controlled location, a site-to-site tunnel will
likely be more efficient, not to mention more convenient and easier to support.

With a site-to-site tunnel the devices on either local network need not have any
knowledge that a VPN exists. No client software is required and all of the work
is handled by the tunnel endpoints. This is also a good solution for devices
that have network support but do not handle VPN connections such as printers,
cameras, HVAC systems, and other embedded hardware.

Site-to-site example configuration

The key to making a working IPsec tunnel is to ensure that both sides have
matching settings for authentication, encryption, and so on. Before starting
make a note of the local and remote WAN IP addresses as well as the local and
remote internal subnets that will be carried across the tunnel. Aside from the
cosmetic tunnel Description pieces is be information
connection settings is be identical .

following settings assumed example subsequent
examples IPsec recipes :

IPsec Endpoint Settings

Site A	Site B
Name	Austin Office	Name	London Office
WAN IP	198.51.100.3	WAN IP	203.0.113.5
LAN Subnet	10.3.0.0/24	LAN Subnet	10.5.0.0/24
LAN IP	10.3.0.1	LAN IP	10.5.0.1

Figure Site-to-Site IPsec shows general layout VPN .

Site-to-Site IPsec

Site A

Start with configuring the tunnel and related settings on the firewall at Site
A.

Phase 1

add new IPsec phase 1 :

Use the following settings for the phase 1 configuration. Many of these settings
may be left at their default values unless otherwise noted.

See also

For comprehensive coverage of all IPsec phase 1 settings, see
Phase 1 Settings.

fill section holds general phase 1 information
IKE endpoint configuration , shown Figurefigure – vpn – tunnel – settings.
Items in bold are required. Fill in the settings as described:

Description:

Text describing the purpose or identity of the tunnel. The best practice is to
put the name of Site B in this box, and brief detail about the purpose of the
tunnel to help with future administration.

For this example ExampleCo London Office is used for the Description
to identify where this example tunnel terminates.

Disabled:

Uncheck this box so that the tunnel will be operational.

Key Exchange version:

Specifies whether to use IKEv2 or IKEv1. IKEv2 is the best practice when
supported by both endpoints. If one side does not support IKEv2, use IKEv1
instead.

Internet Protocol:

IPv4 in most cases unless both WANs have IPv6, in which case either type may
be used.

Interface:

Most likely set to WAN , but see the note at
Interface Selection on selecting the proper interface when
unsure.

Remote Gateway:

The WAN address at Site B, 203.0.113.5 in this example.

Site A IPsec Phase 1 General Information and IKE Endpoint Configuration

The next section controls IPsec phase 1 proposals for authentication. The
defaults are desirable for most of these settings which simplifies the process.

Authentication Method:

The default, Mutual PSK, example .

My Identifier:

The default, My IP Address, kept example .

Peer Identifier:

The default, Peer IP Address, kept example .

Pre-Shared Key:

Use a strong key, at least 10 characters in length containing a mix of upper
and lowercase letters, numbers and symbols. Enter a custom key or click
Generate new Pre-Shared Key to automatically populate
the field random long string suitable for use as a Pre-Shared Key.

Warning

This is the most important setting to get correct. As mentioned in the VPN
overview, IPsec using pre-shared keys can be broken if the tunnel uses a
weak key.

The exact same key must be entered into the tunnel configuration for Site
B later, so note it down or copy and paste it elsewhere. Copy and paste may
come in handy, especially complex key.

Site A Phase 1 Authentication Settings

The next section controls IPsec phase 1 proposals for encryption.

Encryption Algorithm:

Use AES Key Length of 256 bits.

Hash Algorithm:

Use SHA256 if both sides support it, otherwise use the strongest hash
supported by both endpoints.

DH Group:

The default of 14 (2048 bit) is OK, higher values are more secure but may
use more CPU.

Site Phase 1 Encryption Settings

The Expiration and Replacement section controls the timing and method by
which the phase 1 will be renegotiated.

Life Time:

The default 28800 is OK for this endpoint.

lifetime – related values (Rekey Time, Reauth Time, Rand
Time) left defaults endpoint
automatically calculated correct values .

Site Phase 1 Lifetime Settings

Finally, the Advanced section is contains contains couple settings check :

Child SA Close Action:

Set this endpoint to Restart / Reconnect so that the phase 2 entries will be
reconnected if they get disconnected.

Dead Peer Detection:

Leave checked and at the default values.

Site A Phase 1 Advanced Settings

Click Save to complete the phase 1 setup.

Phase 2

With the phase 1 entry complete, now a new phase 2 definition to the VPN:

Site A Phase 2 List (Empty)

Adding a Phase 2 entry to Site A

add settings phase 2 VPN . settings phase 2 ( Figure
Site Phase 2 General Information Networks) can vary more than phase 1.

See also

comprehensive coverage IPsec phase 2 settings ,
Phase 2 Settings.

Description:

A brief description of the network(s) involved in this phase 2 entry.

Mode:

example policy – based tunnel , selectTunnel IPv4

Local Network:

In most cases the best practice is to leave this as LAN Subnet, but it can
be changed to Network proper subnet value filled . case
10.3.0.0/24. Leaving it as LAN Subnet will ensure that if
the network is renumbered in the future, this end of the tunnel will follow.
If that does happen, the other end must be changed manually.

NAT/BINAT:

SetNone.

Remote Network:

Setthe network at Site B, in this case 10.5.0.0/24.

Site Phase 2 General Information Networks

The next section of the phase 2 settings covers traffic encryption. Encryption
algorithms and Hash algorithms can both be set to allow multiple options
in phase 2, and both sides will negotiate and agree upon the settings so long as
each side has at least one of each in common. In some cases that may be a good
thing, but it is usually better to restrict this to the single specific options
desired on both sides.

Protocol:

SetESP for encryption.

Encryption algorithm:

The best practice is to use an AEAD cipher such as AES-GCM if it is supported
by both endpoints.

SelectAES256-GCM 128 bit key length. Otherwise, use AES 256,
highest strength cipher supported endpoints .

Hash algorithm:

AES – GCM selectedEncryption Algorithm do not select any hashes.

Otherwise, use SHA256 or whichever hash supported by both sides is
strongest.

PFS:

Perfect Forward Secrecy (PFS) is optional but can help protect against certain
key attacks. This example uses 14 (2048 bit).

Site Phase 2 Proposal Settings

Next are the settings which govern timing and methods for renewing phase 2 keys.

Life Time:

Use 3600 for this example, and leave Rekey Time and Rand Time at
their default calculated placeholder values.

Site A Phase 2 Expiration and Replacement Settings

finalize settings action :

Apply IPsec Settings

The tunnel configuration for Site A is now complete.

Firewall Rules

Firewall rules are necessary to allow traffic from the network at Site B to
enter through the IPsec tunnel.

Navigate to Firewall > Rules on the IPsec tab add rules
pass traffic remote VPN .

Rules may be as permissive or restrictive as desired. For example, they can
allow any protocol from anywhere to anywhere or only allow TCP from a certain
host on Site B to a certain host at Site A on a certain port.

As with other firewall rules the connections are checked on the way into the
firewall; the source of all traffic on the IPsec tab rules will be remote VPN
networks, such as those at Site B.

Make sure the source addresses on the firewall rules match Site B addresses,
such as 10.5.0.0/24. The destination addresses will be on Site A, such as
10.3.0.0/24.

Site B

Now that Site A is configured, it is time to tackle Site B. Repeat the process
on the Site B endpoint to add a tunnel.

parts is differ setup differ Site shown Figure
Site B Phase 1 General Settings and Figure
Site B Phase 2 General Settings:

• The phase 1 settings for Description, WAN address, Life Time, Child SA Start
  Action, and Child SA Close Action

• phase 2 tunnel networks Life Time

Add a phase 1 entry to the Site B firewall using identical settings used on Site A but
with the following differences:

Description:

ExampleCo Austin Office.

Remote Gateway:

The WAN address at Site A, 198.51.100.3.

Life Time:

10 % higher Site ,31680

Child SA Start Action:

SetNone (Responder Only) so that this endpoint will not initiate on
its own, but will wait for Site A to initiate.

Child SA Close Action:

Set this endpoint to Close Connection and clear SA so that the phase 2
will not automatically reconnect, since Site A will be managing that.

Add a phase 2 entry to the Site B firewall using identical settings used on Site
A but with the following differences.

Description:

ExampleCo Austin LAN.

Remote Subnet:

The network at Site A, in this case 10.3.0.0/24.

Life Time:

10 % higher Site ,5400

Site B Phase 1 General Settings

Site B Phase 1 Other Settings

Site B Phase 2 General Settings

Site B Phase 2 Lifetime Settings

Site , firewall rules added allow traffic tunnel
cross Site Site B. Add rulesIPsec tab
Firewall > Rules. For more details, see IPsec and firewall rules.
This time, the source of the traffic would be Site A, destination Site B.

Check Status

tunnels configured active . Check IPsec status visiting
Status > IPsec. A description of the tunnel is shown along with its status.

If the tunnel is not listed as Established, there may be a problem
establishing the tunnel. This soon, the most likely reason is that no traffic
has attempted to cross the tunnel.

A connect button is offered on this screen that will attempt to initiate the
tunnel. Click the Connect VPN button attempt
bring tunnel seen FigureSite A IPsec Status.

Site A IPsec Status

If the connect button does not appear try to ping a system in the remote subnet
at Site B from a device inside of the phase 2 local network at Site A (or vice
versa) and see if the tunnel establishes. Look at
Testing IPsec Connectivity for other means of testing a tunnel.

Failing that, the IPsec logs will typically offer an explanation. They are
located under Status > System Logs on the IPsec tab. Be sure to check
the status and logs at both sites. For more troubleshooting information, check
the Troubleshooting IPsec VPNs section later in this chapter.

When the tunnel is connected the status will look like Figure
Site A IPsec Status while Connected.

Site A IPsec Status while Connected