summaryrefslogtreecommitdiff
path: root/docs/configuration
diff options
context:
space:
mode:
Diffstat (limited to 'docs/configuration')
-rw-r--r--docs/configuration/vpn/site2site_ipsec.rst167
1 files changed, 128 insertions, 39 deletions
diff --git a/docs/configuration/vpn/site2site_ipsec.rst b/docs/configuration/vpn/site2site_ipsec.rst
index e0156a6f..1a404fa0 100644
--- a/docs/configuration/vpn/site2site_ipsec.rst
+++ b/docs/configuration/vpn/site2site_ipsec.rst
@@ -3,103 +3,151 @@
Site-to-Site
============
-Site-to-site mode provides a way to add remote peers, which could be configured to exchange encrypted information between them and VyOS itself or connected/routed networks.
+Site-to-site mode provides a way to add remote peers, which could be configured
+to exchange encrypted information between them and VyOS itself or connected
+/routed networks.
-To configure site-to-site connection you need to add peers with the ``set vpn ipsec site-to-site`` command.
+To configure site-to-site connection you need to add peers with the ``set vpn
+ipsec site-to-site`` command.
You can identify a remote peer with:
-* IPv4 or IPv6 address. This mode is easiest for configuration and mostly used when a peer has a public static IP address;
-* Hostname. This mode is similar to IP address, only you define DNS name instead of an IP. Could be used when a peer has a public IP address and DNS name, but an IP address could be changed from time to time;
-* Remote ID of the peer. In this mode, there is no predefined remote address nor DNS name of the peer. This mode is useful when a peer doesn't have a publicly available IP address (NAT between it and VyOS), or IP address could be changed.
+* IPv4 or IPv6 address. This mode is easiest for configuration and mostly used
+ when a peer has a public static IP address;
+* Hostname. This mode is similar to IP address, only you define DNS name instead
+ of an IP. Could be used when a peer has a public IP address and DNS name, but
+ an IP address could be changed from time to time;
+* Remote ID of the peer. In this mode, there is no predefined remote address nor
+ DNS name of the peer. This mode is useful when a peer doesn't have a publicly
+ available IP address (NAT between it and VyOS), or IP address could be
+ changed.
Each site-to-site peer has the next options:
-* ``authentication`` - configure authentication between VyOS and a remote peer. Suboptions:
+* ``authentication`` - configure authentication between VyOS and a remote peer.
+ Suboptions:
- * ``id`` - ID for the local VyOS router. If defined, during the authentication it will be send to remote peer;
+ * ``id`` - ID for the local VyOS router. If defined, during the authentication
+ it will be send to remote peer;
* ``mode`` - mode for authentication between VyOS and remote peer:
- * ``pre-shared-secret`` - use predefined shared secret phrase, must be the same for local and remote side;
+ * ``pre-shared-secret`` - use predefined shared secret phrase, must be the
+ same for local and remote side;
- * ``rsa`` - use simple shared RSA key. The key must be defined in the ``set vpn rsa-keys`` section;
+ * ``rsa`` - use simple shared RSA key. The key must be defined in the ``set
+ vpn rsa-keys`` section;
* ``x509`` - use certificates infrastructure for authentication.
- * ``pre-shared-secret`` - predefined shared secret. Used if configured ``mode pre-shared-secret``;
+ * ``pre-shared-secret`` - predefined shared secret. Used if configured ``mode
+ pre-shared-secret``;
- * ``remote-id`` - define an ID for remote peer, instead of using peer name or address. Useful in case if the remote peer is behind NAT or if ``mode x509`` is used;
+ * ``remote-id`` - define an ID for remote peer, instead of using peer name or
+ address. Useful in case if the remote peer is behind NAT or if ``mode x509``
+ is used;
- * ``rsa-key-name`` - shared RSA key for authentication. The key must be defined in the ``set vpn rsa-keys`` section;
+ * ``rsa-key-name`` - shared RSA key for authentication. The key must be defined
+ in the ``set vpn rsa-keys`` section;
- * ``use-x509-id`` - use local ID from x509 certificate. Cannot be used when ``id`` is defined;
+ * ``use-x509-id`` - use local ID from x509 certificate. Cannot be used when
+ ``id`` is defined;
* ``x509`` - options for x509 authentication mode:
- * ``ca-cert-file`` - CA certificate file. Using for authenticating remote peer;
+ * ``ca-cert-file`` - CA certificate file. Using for authenticating remote
+ peer;
- * ``cert-file`` - certificate file, which will be used for authenticating local router on remote peer;
+ * ``cert-file`` - certificate file, which will be used for authenticating
+ local router on remote peer;
- * ``crl-file`` - file with the Certificate Revocation List. Using to check if a certificate for the remote peer is valid or revoked;
+ * ``crl-file`` - file with the Certificate Revocation List. Using to check if
+ a certificate for the remote peer is valid or revoked;
- * ``key`` - a private key, which will be used for authenticating local router on remote peer:
+ * ``key`` - a private key, which will be used for authenticating local router
+ on remote peer:
* ``file`` - path to the key file;
* ``password`` - passphrase private key, if needed.
-* ``connection-type`` - how to handle this connection process. Possible variants:
+* ``connection-type`` - how to handle this connection process. Possible
+ variants:
- * ``initiate`` - do initial connection to remote peer immediately after configuring and after boot. In this mode the connection will not be restarted in case of disconnection, therefore should be used only together with DPD or another session tracking methods;
+ * ``initiate`` - do initial connection to remote peer immediately after
+ configuring and after boot. In this mode the connection will not be
+ restarted in case of disconnection, therefore should be used only together
+ with DPD or another session tracking methods;
- * ``respond`` - do not try to initiate a connection to a remote peer. In this mode, the IPSec session will be established only after initiation from a remote peer. Could be useful when there is no direct connectivity to the peer due to firewall or NAT in the middle of the local and remote side.
+ * ``respond`` - do not try to initiate a connection to a remote peer. In this
+ mode, the IPSec session will be established only after initiation from a
+ remote peer. Could be useful when there is no direct connectivity to the
+ peer due to firewall or NAT in the middle of the local and remote side.
-* ``default-esp-group`` - ESP group to use by default for traffic encryption. Might be overwritten by individual settings for tunnel or VTI interface binding;
+* ``default-esp-group`` - ESP group to use by default for traffic encryption.
+ Might be overwritten by individual settings for tunnel or VTI interface
+ binding;
* ``description`` - description for this peer;
-* ``dhcp-interface`` - use an IP address, received from DHCP for IPSec connection with this peer, instead of ``local-address``;
+* ``dhcp-interface`` - use an IP address, received from DHCP for IPSec
+ connection with this peer, instead of ``local-address``;
-* ``force-encapsulation`` - force encapsulation of ESP into UDP datagrams. Useful in case if between local and remote side is firewall or NAT, which not allows passing plain ESP packets between them;
+* ``force-encapsulation`` - force encapsulation of ESP into UDP datagrams.
+ Useful in case if between local and remote side is firewall or NAT, which
+ not allows passing plain ESP packets between them;
* ``ike-group`` - IKE group to use for key exchanges;
-* ``ikev2-reauth`` - reauthenticate remote peer during the rekeying process. Can be used only with IKEv2:
+* ``ikev2-reauth`` - reauthenticate remote peer during the rekeying process.
+ Can be used only with IKEv2:
- * ``yes`` - create a new IKE_SA from the scratch and try to recreate all IPsec SAs;
+ * ``yes`` - create a new IKE_SA from the scratch and try to recreate all
+ IPsec SAs;
* ``no`` - rekey without uninstalling the IPsec SAs;
* ``inherit`` - use default behavior for the used IKE group.
-* ``local-address`` - local IP address for IPSec connection with this peer. If defined ``any``, then an IP address which configured on interface with default route will be used;
+* ``local-address`` - local IP address for IPSec connection with this peer. If
+ defined ``any``, then an IP address which configured on interface with default
+ route will be used;
-* ``tunnel`` - define criteria for traffic to be matched for encrypting and send it to a peer:
+* ``tunnel`` - define criteria for traffic to be matched for encrypting and
+ send it to a peer:
* ``disable`` - disable this tunnel;
* ``esp-group`` - define ESP group for encrypt traffic, defined by this tunnel;
- * ``local`` - define a local source for match traffic, which should be encrypted and send to this peer:
+ * ``local`` - define a local source for match traffic, which should be
+ encrypted and send to this peer:
* ``port`` - define port. Have effect only when used together with ``prefix``;
* ``prefix`` - IP network at local side.
- * ``protocol`` - define the protocol for match traffic, which should be encrypted and send to this peer;
+ * ``protocol`` - define the protocol for match traffic, which should be
+ encrypted and send to this peer;
- * ``remote`` - define the remote destination for match traffic, which should be encrypted and send to this peer:
+ * ``remote`` - define the remote destination for match traffic, which should
+ be encrypted and send to this peer:
* ``port`` - define port. Have effect only when used together with ``prefix``;
* ``prefix`` - IP network at remote side.
-* ``vti`` - use a VTI interface for traffic encryption. Any traffic, which will be send to VTI interface will be encrypted and send to this peer. Using VTI makes IPSec configuration much flexible and easier in complex situation, and allows to dynamically add/delete remote networks, reachable via a peer, as in this mode router don't need to create additional SA/policy for each remote network:
+* ``vti`` - use a VTI interface for traffic encryption. Any traffic, which will
+ be send to VTI interface will be encrypted and send to this peer. Using VTI
+ makes IPSec configuration much flexible and easier in complex situation, and
+ allows to dynamically add/delete remote networks, reachable via a peer, as in
+ this mode router don't need to create additional SA/policy for each remote
+ network:
* ``bind`` - select a VTI interface to bind to this peer;
- * ``esp-group`` - define ESP group for encrypt traffic, passed this VTI interface.
+ * ``esp-group`` - define ESP group for encrypt traffic, passed this VTI
+ interface.
Examples:
------------------
@@ -216,9 +264,15 @@ rules. (if you used the default configuration at the top of this page)
IKEv2
^^^^^
+Example:
+
+* left local_ip: 192.168.0.10 # VPN Gateway, behind NAT device
+* left public_ip:172.18.201.10
+* right local_ip: 172.18.202.10 # right side WAN IP
+
Imagine the following topology
-.. figure:: /_static/images/vpn_s2s_ikev2.png
+.. figure:: /_static/images/vpn_s2s_ikev2_c.png
:scale: 50 %
:alt: IPSec IKEv2 site2site VPN
@@ -240,9 +294,6 @@ Imagine the following topology
set vpn ipsec esp-group ESP_DEFAULT pfs 'dh-group19'
set vpn ipsec esp-group ESP_DEFAULT proposal 10 encryption 'aes256gcm128'
set vpn ipsec esp-group ESP_DEFAULT proposal 10 hash 'sha256'
- set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection action 'hold'
- set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection interval '30'
- set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection timeout '120'
set vpn ipsec ike-group IKEv2_DEFAULT ikev2-reauth 'no'
set vpn ipsec ike-group IKEv2_DEFAULT key-exchange 'ikev2'
set vpn ipsec ike-group IKEv2_DEFAULT lifetime '10800'
@@ -255,10 +306,10 @@ Imagine the following topology
set vpn ipsec site-to-site peer 172.18.202.10 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 172.18.202.10 authentication pre-shared-secret 'secretkey'
set vpn ipsec site-to-site peer 172.18.202.10 authentication remote-id '172.18.202.10'
- set vpn ipsec site-to-site peer 172.18.202.10 connection-type 'initiate'
+ set vpn ipsec site-to-site peer 172.18.202.10 connection-type 'respond'
set vpn ipsec site-to-site peer 172.18.202.10 ike-group 'IKEv2_DEFAULT'
set vpn ipsec site-to-site peer 172.18.202.10 ikev2-reauth 'inherit'
- set vpn ipsec site-to-site peer 172.18.202.10 local-address '172.18.201.10'
+ set vpn ipsec site-to-site peer 172.18.202.10 local-address '192.168.0.10'
set vpn ipsec site-to-site peer 172.18.202.10 vti bind 'vti10'
set vpn ipsec site-to-site peer 172.18.202.10 vti esp-group 'ESP_DEFAULT'
@@ -274,7 +325,7 @@ Imagine the following topology
set vpn ipsec esp-group ESP_DEFAULT pfs 'dh-group19'
set vpn ipsec esp-group ESP_DEFAULT proposal 10 encryption 'aes256gcm128'
set vpn ipsec esp-group ESP_DEFAULT proposal 10 hash 'sha256'
- set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection action 'hold'
+ set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection action 'restart'
set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection interval '30'
set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection timeout '120'
set vpn ipsec ike-group IKEv2_DEFAULT ikev2-reauth 'no'
@@ -296,4 +347,42 @@ Imagine the following topology
set vpn ipsec site-to-site peer 172.18.201.10 vti bind 'vti10'
set vpn ipsec site-to-site peer 172.18.201.10 vti esp-group 'ESP_DEFAULT'
+
+Key Parameters:
+
+* ``authentication id/remote-id`` - IKE identification is used for validation
+ of VPN peer devices during IKE negotiation. If you do not configure local/
+ remote-identity, the device uses the IPv4 or IPv6 address that corresponds
+ to the local/remote peer by default.
+ In certain network setups (like ipsec interface with dynamic address, or
+ behind the NAT ), the IKE ID received from the peer does not match the IKE
+ gateway configured on the device. This can lead to a Phase 1 validation
+ failure.
+ So, make sure to configure the local/remote id explicitly and ensure that the
+ IKE ID is the same as the remote-identity configured on the peer device.
+
+* ``disable-route-autoinstall`` - This option when configured disables the
+ routes installed in the default table 220 for site-to-site ipsec.
+ It is mostly used with VTI configuration.
+
+* ``dead-peer-detection action = clear | hold | restart`` - R_U_THERE
+ notification messages(IKEv1) or empty INFORMATIONAL messages (IKEv2)
+ are periodically sent in order to check the liveliness of theIPsec peer. The
+ values clear, hold, and restart all activate DPD and determine the action to
+ perform on a timeout.
+ With ``clear`` the connection is closed with no further actions taken.
+ ``hold`` installs a trap policy, which will catch matching traffic and tries
+ to re-negotiate the connection on demand.
+ ``restart`` will immediately trigger an attempt to re-negotiate the
+ connection.
+
+* ``close-action = none | clear | hold | restart`` - defines the action to take
+ if the remote peer unexpectedly closes a CHILD_SA (see above for meaning of
+ values). A closeaction should not be used if the peer uses reauthentication or
+ uniqueids.
+
+ For a responder, close-action or dead-peer-detection must not be enabled.
+ For an initiator DPD with `restart` action, and `close-action 'restart'`
+ is recommended in IKE profile.
+
.. _RFC3031: https://tools.ietf.org/html/rfc3021
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 22:59:22 +0000