Site-to-Site VPN Connections

A VPN connection that makes it possible to interconnect the local networks of remote offices is called a Site-to-Site VPN.

In this case, one firewall works as a VPN server and another as a VPN client. The client initiates a connection to the server. A Site-to-Site VPN can be created between two UserGate firewalls or between a UserGate firewall and a third-party device.

To create a Site-to-Site VPN, L2TP/IPsec(IKEv1) and IKEv2/IPsec protocols are used.

Configuring Site-to-Site VPN Using Admin Console

Creating a Site-to-Site VPN requires that the relevant settings be configured at both endpoints of the secure connection, i.e., the VPN server and VPN client.

VPN Server Host Configuration

Name

Description

Step 1. Create a local user for the authentication of the VPN client server.

This login name is used for authenticating the VPN client host only during the establishment an L2TP tunnel in the L2TP/IPsec VPN scenario.

In the Users and devices ➜ Users section, create a user for each of the remote hosts that will work as VPN clients, and set passwords for the users. For convenience, all such users thus created can be placed in the existing VPN servers group that will be granted VPN connection access.

Step 2. Allow the VPN service in the zone to which VPN clients will connect.

In the Network ➜ Zones section, edit the access control settings for the zone to which VPN clients will connect and enable the VPN service. Usually, this is the Untrusted zone.

Step 3. Create a zone where the servers connecting using a VPN will be placed.

In the Network ➜ Zones section, create a zone where the servers connecting via a VPN will be placed. This zone can later be used in security policies.

As an example, a zone called VPN for Site-to-Site is created in the admin console.

Step 4. If required, create a firewall rule that allows traffic from the zone created earlier.

To grant VPN users access to certain network segments or, for example, Internet, go to Network policies ➜ Firewall and create a firewall rule that allows traffic from the zone just created to the desired zones.

In the admin console, there is a predefined rule named VPN for Site-to-Site to Trusted and Untrusted that allows all traffic from the zone VPN for Site-to-Site to the Trusted and Untrusted zones. This rule is disabled by default.

To let the traffic pass to the client via the VPN tunnel from the desired server zone, you need to create an allowing firewall rule, specifying that zone as the source and, for example, VPN for Site-to-Site as the destination zone.

Step 5. Create an authentication profile if it is required.

If required, create an authentication profile for VPN users in the Users and devices ➜ Auth profiles section. The same authentication profile may be used that you use to authenticate users for Internet access. Note that transparent authentication methods such as Kerberos, NTLM, or SAML IDP cannot be used for VPN authentication.

For more details on authentication profiles, see the Authentication Profiles section.

Step 6. Create a VPN security profile.

In the VPN security profile settings, the types and settings of encryption and authentication algorithms are defined. Multiple security profiles may be used for connecting to different client types.

Security profiles for the VPN server and VPN client hosts are configured separately in the VPN section of the admin console. To create a VPN server security profile, go to VPN ➜ Server security profiles, click Add, and fill in these fields:

  • Name: the name of the security profile

  • Description: a description of the security profile

  • IKE (Internet Key Exchange) protocol version. The options are as follows:

    • IKEv1: create a secure link using IKEv1

    • IKEv2: create a secure link using IKEv2

When IKEv1 is selected, the following fields are available:

  • IKE mode:

    • main: use the main IKEv1 mode

    • aggressive: use the aggressive IKEv1 mode.

  • ID type: the type of IKE local ID parameter. This is required for the identification of the neighbor host when establishing a VPN connection to certain vendors' equipment. Enumerated selection options:

    • None: the default value of the field. Used when the IKE local ID parameter is not required for establishing a VPN connection. For example, when a VPN connection between two UserGate nodes is established.

    • IPv4: the host's IP address.

    • FQDN: the host's address in the fully-qualified domain name (FQDN) format.

    • CIDR: the host's address in the classless inter-domain routing (CIDR) format.

  • ID value: the IKE local ID value in the format specified above.

  • Pre-shared key: authenticate the remote node using pre-shared key. This string must match on the client and server for a successful connection.

When IKEv2 is selected, the following fields are available:

  • ID type: the type of IKE local ID parameter. This is required for the identification of the neighbor host when establishing a VPN connection to certain vendors' equipment. Enumerated selection options:

    • None: the default value of the field. Used when the IKE local ID parameter is not required for establishing a VPN connection. For example, when a VPN connection between two UserGate nodes is established.

    • IPv4: the host's IP address.

    • FQDN: the host's address in the fully-qualified domain name (FQDN) format.

    • CIDR: the host's address in the classless inter-domain routing (CIDR) format.

  • ID value: the IKE local ID value in the format specified above.

  • Server certificate: select a pre-created server certificate for authentication using certificates based on a Public Key Infrastructure (PKI). For examples of how to create and use certificates for IKEv2 VPN, refer to the Appendix.

  • Auth mode: whether to authenticate using PKI-based certificates or the EAP protocol with MSCHAPv2 (AAA) method (the option for a Remote Access VPN). When PKI-based authentication is used, specify a pre-configured user certificate profile here. For more details on profiles, see the Client Certificate Profiles section.

Next, the settings for the first and second phases of secure connection negotiation need to be configured.

In the first phase, an IKE SA is negotiated and established. The authentication is done using a pre-shared key in the mode selected earlier. Provide the following settings:

  • Key lifetime: the time period after which the parties re-authenticate and re-negotiate the first-phase settings.

  • Dead peer detection: the Dead Peer Detection (DPD) mechanism is used to check the functionality of the channel and timely disconnect/reconnect it when the connection is lost. DPD sends R-U-THERE messages periodically to check if the IPsec neighbor is available. There are 3 operating modes of the mechanism:

    • off: the mechanism is disabled.​ DPD requests are not sent.

    • always on: DPD requests are always sent within the specified time interval. If no response is received, additional requests are sent sequentially at intervals of 5 seconds in the number specified in the Failures field. If there is a response, the mechanism returns to the initial interval for sending DPD requests, and if there is no response, the connection is terminated.

    • Idle: DPD requests are not sent while there is ESP traffic through the created SAs. If there are no packets within twice the specified time interval, then a DPD request is sent. If there is a response, a new DPD request will be sent again after a double interval of the specified time. If no response is received, additional requests are sent sequentially at intervals of 5 seconds in the number specified in the Failures field. If there is no response, the connection is terminated.

  • Diffie-Hellman groups: select the Diffie-Hellman group that will be used for key exchange.

  • Security: the algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse or use the Up/Down buttons.

In the second phase, the method for securing data in the IPsec connections is selected. You need to specify the following:

  • Key lifetime: the time period after which the nodes must rotate the encryption key. The lifetime for the second phase is shorter than for the first one, which entails a more frequent key rotation.

  • Key lifesize: the key lifetime can also be expressed in bytes and is called lifesize in that case. If both values (Key lifetime and Key lifesize) are specified, the counter that reaches the limit first will trigger session key re-generation.

  • Enable NAT keepalive: used in scenarios when IPsec traffic goes through a NAT node. NAT table entries are active for a limited time. If there was no VPN traffic over the tunnel during that time span, NAT table entries on the NAT host will be deleted, preventing further passage of VPN traffic. The VPN server located behind the NAT gateway uses NAT keepalive function to periodically send keepalive packets to a peer node in order to keep the NAT session active.

  • Security: the algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse or use the Up/Down buttons.

In the admin console, there is a predefined security profile named Site-to-Site VPN profile that provides the required settings. If you plan to use this profile, make sure to change the pre-shared encryption key when the IKEv1/IPsec protocols are used.

Step 7. Create a VPN interface.

A VPN interface is a virtual network adapter that will be used to connect VPN clients. This is a cluster-type interface, which means that it will be created automatically on all UserGate nodes included in a configuration cluster. If an HA cluster exists, in case any problems are identified with the active server, VPN clients will be automatically switched to a backup server, and without terminating existing VPN connections.

In the Network ➜ Interfaces section, click Add and select Add VPN. Provide the following settings:

  • Name: the name of the interface. Should be in the form tunnelN, where N is the ordinal number of the VPN interface.

  • Description: a description of the interface.

  • All clients with a VPN connection to NGFW will be placed in the same zone. Specify the zone created at Step 3.

  • Netflow profile: the Netflow profile used for this interface. This parameter is optional.

  • Mode: the IP address assignment type, such as no address, a static IP address, or a dynamic IP address obtained using DHCP. If the interface is to be used for accepting VPN connections (Site-2-Site VPN or Remote access VPN), a static IP address must be used.

  • MTU: the MTU size for the selected interface. If packets transmitted over the VPN tunnel exceed the maximum MTU at any of the intermediate devices, they can be split into fragments. This can increase the latency and reduce the performance. By setting an optimum MTU value on the tunnel interface, you can avoid packet fragmentation and reduce the latency.

As an example, there is a predefined VPN interface named tunnel2 in the admin console that is recommended for use as a site-to-site VPN interface.

Step 8. Create a VPN network.

A VPN determines the network settings that will be used for connecting the client to the server. This is primarily the assignment of IP addresses to the clients inside the tunnel, the DNS settings, and the routes that will be passed to the clients that support the use of routes assigned to them. Multiple tunnels may be used with different settings for different clients.

To create a VPN tunnel, go to VPN ➜ VPN networks, click Add, and fill in these fields:

  • Name: the name of the network.

  • Description: a description of the network.

  • IP address range: the range of IP addresses that will be used by the clients and server. Exclude the addresses assigned to the VPN interface used with this network from the range. Do not enter network addresses or the broadcast address here.

  • Specify the DNS servers that will be passed to the client or set the Use system DNS checkbox, in which case the client will be assigned the DNS servers used by NGFW.

    Important! A maximum of two DNS servers can be specified.

  • VPN routes: the routes sent to the client in the CIDR format or a predefined IP address list.

  • UserGate client routes: the tab used to configure the routes sent to the UserGate client. Not used for configuring Site-to-Site VPN connections.

As an example, there is a predefined network in the admin console named Site-to-Site VPN network with the default settings. To use this network, you need to add routes that will be passed to the client server.

To allow the VPN server to know about the client's subnets, configure a static route on the server by specifying the VPN tunnel address used on the client server as the destination address.

Step 9. Create a VPN server rule.

Create a VPN server rule using the network and VPN server security profile created earlier. To create the rule, go to VPN ➜ Server rules, click Add, and fill in these fields:

  • Enabled: enables or disables the rule.

  • Name: the name of the rule.

  • Description: a description of the rule.

  • VPN Security profile: the VPN server security profile created earlier.

  • VPN network: the VPN network created earlier.

  • Auth profile: the authentication profile created earlier.

  • Interface: the VPN interface created earlier.

  • Source: the zones and IP addresses from which VPN connections are allowed. Normally, the clients are on the Internet, so specify the Untrusted zone.

    Important! The traffic processing logic is as follows:

    • The conditions are combined using Boolean OR, if several IP address and/or domain lists are specified.

    • The conditions are combined using Boolean AND, if GeoIPs and IP address and/or domain lists are specified.

  • Destination: one or more interface addresses to which the clients will connect. The interface must belong to the zone specified at Step 2.

  • Users: a group of server accounts or individual server accounts for which VPN connections are allowed.

As an example, a server rule is created in the admin console named Site-to-Site VPN rule that provides the required settings for a site-to-site VPN, and VPN access is allowed for the members of the VPN servers local group.

Important! To apply different server rules to different clients, use the Source zone and Source address settings. The Users setting does not govern the selection of a server rule, as the user is checked only after the VPN connection has been established.
Note When changing the VPN server settings (changing server rules, changing security profiles, adding new VPN networks), the VPN server does not reboot, so previously established active VPN client sessions are not terminated. A reboot of the VPN server and reconnection of active VPN client sessions may occur if the IP address of the tunnel interface of the VPN server is changed.

VPN Client Host Configuration

Name

Description

Step 1. Create a zone where the interface used for VPN connections will be placed.

In the Network ➜ Zones section, create a zone where the interfaces used for VPN connections will be placed. This zone can later be used in security policies.

As an example, a zone called VPN for Site-to-Site is created in the admin console.

Step 2. If required, create a firewall rule that allows traffic to the zone created earlier.

If required, create a firewall rule that allows traffic in the Network policies ➜ Firewall section.

In the admin console, there is a predefined rule named VPN for Site-to-Site to Trusted and Untrusted that allows all traffic between the VPN for Site-to-Site, Trusted, and Untrusted zones.

To let the traffic pass to the server via the VPN tunnel from the desired client server zone, you need to create an allowing firewall rule, specifying the desired source zone and destination zone --- for example, VPN for Site-to-Site.

Step 3. Create a VPN security profile.

In the VPN security profile settings, the types and settings of encryption and authentication algorithms are defined. Multiple security profiles may be used for connecting to different client types.

In the VPN section, security profiles are created for the VPN server and client. To create a VPN client security profile, go to VPN ➜ Client security profiles, click Add, and fill in these fields:

  • Name: the name of the security profile

  • Description: the description of the profile

  • Protocol: the protocol used to establish a VPN link between the two networks. The options are as follows:

    • IPsec L2TP: create a secure VPN link using L2TP and IPsec/IKEv1

    • IPsec: create a secure VPN link to a VPN server using IPsec/IKEv1

    • IKEv2 with certificate: create a secure VPN link using IKEv2 with authentication using a certificate based on the Public Key Infrastructure (PKI).

When IPsec L2TP is selected, the following fields are available:

  • IKE mode:

    • main: use the main IKEv1 mode

    • aggressive: use the aggressive IKEv1 mode.

  • ID type: the type of IKE local ID parameter. This is required for the identification of the neighbor host when establishing a VPN connection to certain vendors' equipment. Enumerated selection options:

    • None: the default value of the field. Used when the IKE local ID parameter is not required for establishing a VPN connection. For example, when a VPN connection between two UserGate nodes is established.

    • IPv4: the host's IP address.

    • FQDN: the host's address in the fully-qualified domain name (FQDN) format.

    • CIDR: the host's address in the classless inter-domain routing (CIDR) format.

  • ID value: the IKE local ID value in the format specified above.

  • Pre-shared key: authenticate the remote node using pre-shared key. This string must match on the client and server for a successful connection.

  • Authentication: the login and password created at Step 1 for VPN client authentication when configuring a VPN server.

When IPsec is selected, the following fields are available:

  • IKE mode:

    • main: use the main IKEv1 mode

    • aggressive: use the aggressive IKEv1 mode.

  • ID type: the type of IKE local ID parameter. This is required for the identification of the neighbor host when establishing a VPN connection to certain vendors' equipment. Enumerated selection options:

    • None: the default value of the field. Used when the IKE local ID parameter is not required for establishing a VPN connection. For example, when a VPN connection between two UserGate nodes is established.

    • IPv4: the host's IP address.

    • FQDN: the host's address in the fully-qualified domain name (FQDN) format.

    • CIDR: the host's address in the classless inter-domain routing (CIDR) format.

  • ID value: the IKE local ID value in the format specified above.

  • Pre-shared key: authenticate the remote node using pre-shared key. This string must match on the client and server for a successful connection.

  • Subnets for VPN:

    • Local subnet: the IP address of an allowed local subnet.

    • Remote subnet: the IP address of an allowed subnet on the remote VPN server side.

When IKEv2 with certificate is selected, the following fields are available:

  • ID type: the type of IKE local ID parameter. This is required for the identification of the neighbor host when establishing a VPN connection to certain vendors' equipment. Enumerated selection options:

    • None: the default value of the field. Used when the IKE local ID parameter is not required for establishing a VPN connection. For example, when a VPN connection between two UserGate nodes is established.

    • IPv4: the host's IP address.

    • FQDN: the host's address in the fully-qualified domain name (FQDN) format.

    • CIDR: the host's address in the classless inter-domain routing (CIDR) format.

  • ID value: the IKE local ID value in the format specified above.

  • Client certificate: select a VPN client certificate based on the Public Key Infrastructure (PKI) for authentication. For examples of how to create and use certificates for IKEv2 VPN, refer to the Appendix.

Next, the settings for the first and second phases of tunnel negotiation need to be configured.

In the first phase, an IKE SA is negotiated and established. The authentication is done using a pre-shared key in the mode selected earlier. Provide the following settings:

  • Key lifetime: the time period after which the parties re-authenticate and re-negotiate the first-phase settings.

  • Dead peer detection: the Dead Peer Detection (DPD) mechanism is used to check the functionality of the channel and timely disconnect/reconnect it when the connection is lost. DPD sends R-U-THERE messages periodically to check if the IPsec neighbor is available. There are 3 operating modes of the mechanism:

    • off: the mechanism is disabled.​ DPD requests are not sent.

    • always on: DPD requests are always sent within the specified time interval. If no response is received, additional requests are sent sequentially at intervals of 5 seconds in the number specified in the Failures field. If there is a response, the mechanism returns to the initial interval for sending DPD requests, and if there is no response, the connection is terminated.

    • Idle: DPD requests are not sent while there is ESP traffic through the created SAs. If there are no packets within twice the specified time interval, then a DPD request is sent. If there is a response, a new DPD request will be sent again after a double interval of the specified time. If no response is received, additional requests are sent sequentially at intervals of 5 seconds in the number specified in the Failures field. If there is no response, the connection is terminated.

  • Diffie-Hellman groups: select the Diffie-Hellman group that will be used for key exchange.

  • Security: the algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse or use the Up/Down buttons.

In the second phase, the method for securing data in the IPsec connections is selected. Specify the following parameters:

  • Key lifetime: the time period after which the nodes must rotate the encryption key. The lifetime for the second phase is shorter than for the first one, which entails a more frequent key rotation.

  • Key lifesize: the key lifetime can also be expressed in bytes and is called lifesize in that case. If both values (Key lifetime and Key lifesize) are specified, the counter that reaches the limit first will trigger session key re-generation.

  • Enable NAT keepalive: used in scenarios when IPsec traffic goes through a NAT node. NAT table entries are active for a limited time. If there was no VPN traffic over the tunnel during that time span, NAT table entries on the NAT host will be deleted, preventing further passage of VPN traffic. The VPN server located behind the NAT gateway uses NAT keepalive function to periodically send keepalive packets to a peer node in order to keep the NAT session active.

  • Security: the authentication and encryption algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse or use the Up/Down buttons.

As an example, a profile named Site-to-Site VPN profile is created in the admin console that provides the required settings. If you plan to use this profile, make sure to change the pre-shared encryption key when the IPsec L2TP and IPsec protocols are used.

Step 4.. Create a VPN interface.

A VPN interface is a virtual network adapter that will be used to connect VPN clients. This is a cluster-type interface, which means that it will be created automatically on all UserGate nodes included in a configuration cluster. If an HA cluster exists, in case any problems are identified with the active server, VPN clients will be automatically switched to a backup server, and without terminating existing VPN connections.

In the Network ➜ Interfaces section, click Add and select Add VPN. Provide the following settings:

  • Name: the name of the interface. Should be in the form tunnelN, where N is the ordinal number of the VPN interface.

  • Description: a description of the interface.

  • Zone: the zone to which this interface will belong. All clients with a VPN connection to NGFW will be placed in the same zone. Specify the zone created at Step 1.

  • Netflow profile: the Netflow profile used for this interface. This parameter is optional.

  • Mode: the IP address assignment type, such as no address, a static IP address, or a dynamic IP address obtained using DHCP. To use the interface as a client VPN interface, use the Dynamic IP assignment mode.

  • MTU: the MTU size for the selected interface. If packets transmitted over the VPN tunnel exceed the maximum MTU at any of the intermediate devices, they can be split into fragments. This can increase the latency and reduce the performance. By setting an optimum MTU value on the tunnel interface, you can avoid packet fragmentation and reduce the latency.

As an example, a VPN interface named tunnel3 is created in the admin console that can be used for a client Site-to-Site VPN connection.

Important! If you select the same example tunnel interface with the default settings in the VPN server and VPN client configuration sections, an IP address conflict will arise during the establishment of a client-to-server connection. For things to work correctly, the address ranges of the tunnel interfaces should not overlap. Make sure to set unique address ranges on the client and server.

Step 5. Create a VPN client rule.

Create a VPN client rule that will initiate a VPN server connection. To create the rule, go to VPN ➜ Client rules, click Add, and fill in these fields:

  • Enabled: enables or disables the rule.

  • Name: the name of the rule.

  • Description: a description of the rule.

  • Security profile: the VPN client security profile created earlier.

  • Interface: the VPN interface created earlier.

  • VPN server address: the IP address of the VPN server to which this VPN client will connect. It is usually the IP address of an interface in the Untrusted zone on NGFW that acts as a VPN server.

When the VPN server and client have been configured, the client initiates a connection to the server, and if the settings are correct, a VPN tunnel is brought up. To bring down the tunnel, disable the VPN client rule (set on the client) or the VPN server rule (set on the server).

Configuring Site-to-Site VPN Using CLI

This example shows the creation of a Site-to-Site VPN using the L2TP/IPsec protocols.

VPN Server Host Configuration

Step 1. Create a local user for the authentication of the VPN client server.

Use the following command:

Admin@nodename# create users user <parameters>

To learn more about the commands and parameters for creating local users using the CLI, see the Configuring Users article.

Here is an example command that creates a user named VPN-client 1 with the login vpn_client1 and adds the user to the VPN servers group:

Admin@nodename# create users user name "VPN-client 1" login vpn_client1 groups [ "VPN servers" ] enabled on

Step 2. Allow the VPN service in the zone to which VPN clients will connect.

To edit the zone parameters, use the following command:

Admin@nodename# set network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that edits the Untrusted zone to allow the VPN service inside it:

Admin@nodename# set network zone Untrusted enabled-services [ VPN ]

Step 3. Create a zone where the servers connecting using a VPN will be placed.

To create a zone, use the following command:

Admin@nodename# create network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that creates a zone called S2S_VPN:

Admin@nodename# create network zone name S2S_VPN enabled-services [ VPN ]

Step 4. If required, create a firewall rule that allows traffic from the zone created earlier to the desired network segment.

Firewall rules are created using a command that employs the UPL syntax:

Admin@nodename# create network-policy firewall <position> upl-rule <commands>

For more details on how to configure firewall rules using the CLI, see the Configuring Firewall Rules article.

An example of creating firewall rules that allow traffic from the zone S2S_VPN to the zone Zone1 is shown below. To let the traffic pass to the client in Zone1 from the desired server zone via the VPN tunnel, you also need to create an allowing firewall rule, specifying the desired source and destination zones.

Admin@nodename# create network-policy firewall 1 upl-rule PASS \ ...src.zone = S2S_VPN \ ...dst.zone = Zone1 \ ...rule_log(session) \ ...name("S2S_VPN to Zone1") \ ...enabled(true) Admin@nodename# create network-policy firewall 2 upl-rule PASS \ ...src.zone = Zone1 \ ...dst.zone = S2S_VPN \ ...rule_log(session) \ ...name("Zone1 to S2S_VPN") \ ...enabled(true)

Step 5. Create an authentication profile for VPN users.

For more details on configuring authentication profiles using the CLI, see the Configuring Authentication Profiles article.

Here are example commands that create an LDAP authentication server named New ldap server for the domain testd.local and authentication profile named New profile:

Admin@nodename# create users auth-server ldap name "New ldap server" address 192.168.1.2 domains [ test.local ] bind-dn test@test.local password 12345 enabled on Admin@nodename# create users auth-profile name "New profile" auth-methods ldap [ "New ldap server" ]

Step 6. Create a VPN server security profile.

To create a VPN server security profile, use the following command:

Admin@nodename# create vpn server-security-profiles <parameters>

For more details on configuring VPN security profiles using the CLI, see the Configuring VPN Security Profiles article.

Here is an example command that creates a VPN server security profile named "New VPN-server profile" for a L2TP/IPsec VPN:

Admin@nodename# create vpn server-security-profiles name "New VPN-server profile" ike-version 1 ike-mode main psk 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ] Repeat preshared key: Admin@nodename#

Step 7. Create a VPN interface.

To create a VPN interface, use the following command:

Admin@nodename# create network interface vpn <parameters>

For more details on how to create a VPN interface using the CLI, see the Interfaces article.

Here is an example command that creates a VPN interface named tunnel4 belonging to the zone S2S_VPN:

Admin@nodename# create network interface vpn interface-name 4 zone S2S_VPN ip-addresses [ 172.30.251.1/24 ] enabled on

Step 8. Create a VPN network.

To create a VPN network, use the following command:

Admin@nodename# create vpn networks <parameters>

For more details on how to create a VPN network using the CLI, see the Configuring VPN Networks article.

Here is an example command that creates a VPN network named "New VPN network":

Admin@nodename# create vpn networks name "New VPN network" ip-range 172.30.251.2-172.30.251.200 mask 255.255.255.0 use-system-dns on routes-ip-list [ "Int net address" ]

Step 9. Create a VPN server rule.

VPN server rules are created using a command that employs the UPL syntax:

Admin@nodename# create vpn server-rules <position> upl-rule <commands>

For more details on how to create VPN server rules using the CLI, see the Configuring Server Rules article.

Here is an example command that creates a VPN server rule named "New VPN-server rule" using the following previously defined items: VPN server security profile "New VPN-server profile", VPN network "New VPN network", user authentication profile "New profile", VPN interface tunnel4, and VPN server external IP address list "Ext VPN address":

Admin@nodename# create vpn server-rules 1 upl-rule OK \ ...name("New VPN-server rule") \ ...profile("New VPN-server profile") \ ...vpn_network("New VPN network") \ ...auth_profile("New profile") \ ...interface(tunnel4) \ ...src.zone = Untrusted ...dst.ip = lib.network("Ext VPN address") ...user = (vpn_client1) ...enabled(true)

VPN Client Host Configuration

Step 1. Create a zone where the interface used for VPN connections will be placed.

Here is an example command that creates a zone called S2S_VPN:

Admin@nodename# create network zone name S2S_VPN enabled-services [ VPN ]

Step 2. Create a firewall rule that allows traffic to the zone created earlier if it is required.

Here is an example of creating firewall rules for a zone named Zone2:

Admin@nodename# create network-policy firewall 1 upl-rule PASS \ ...src.zone = S2S_VPN \ ...dst.zone = Zone2 \ ...rule_log(session) \ ...name("S2S_VPN to Zone2") \ ...enabled(true) Admin@nodename# create network-policy firewall 2 upl-rule PASS \ ...src.zone = Zone2 \ ...dst.zone = S2S_VPN \ ...rule_log(session) \ ...name("Zone2 to S2S_VPN") \ ...enabled(true)

Step 3. Create a VPN client security profile.

To create a VPN client security profile, use the following command:

Admin@nodename# create vpn client-security-profiles <parameters>

For more details on configuring VPN security profiles using the CLI, see the Configuring VPN Security Profiles article.

Here is an example command that creates a VPN client security profile named "New VPN-client profile" for a L2TP/IPsec VPN:

Admin@nodename# create vpn client-security-profiles name "New VPN-client profile" protocol ipsec2 ike-mode main psk 12345 authentication-login vpn_client1 authentication-password 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ] Repeat preshared key: Admin@nodename#

Step 4. Create a VPN interface.

Here is an example command that creates a VPN interface named tunnel5 belonging to the zone S2S_VPN:

Admin@nodename# create network interface vpn interface-name 5 zone S2S_VPN iface-mode dynamic enabled on

Step 5. Create a VPN client rule.

VPN client rules are created using a command that employs the UPL syntax:

Admin@nodename# create vpn client-rules <position> upl-rule <commands>

For more details on how to create VPN client rules using the CLI, see the Configuring Client Rules section.

Here is an example command that creates a VPN client rule named "New VPN-client rule" using the following previously defined items: VPN client security profile "New VPN-client profile", VPN interface tunnel5, and VPN server IP address 10.10.0.1:

Admin@nodename# create vpn client-rules 2 upl-rule OK \ ...name("New VPN-client rule") \ ...profile("New VPN-client profile") \ ...interface(tunnel5) \ ...server_address("10.10.0.1") \ ...enabled(true)