Huawei vpn ipsec настройка

Пока что в серии криптосистем мы познакомились с общей терминологией криптографии и криптосистемой SSH (включая её конфигурацию). Сегодняшнюю статью я начну с с описания того, как работает VPN, а затем расскажу о стандарте IPSec.

VPN, или Virtual Private Network, что в переводе означает Виртуальная Частная Сеть — это криптосистема, позволяющая защитить данные при передаче их по незащищенной сети, такой как Интернет. Несмотря на то, что данное описание подходит и для криптосистемы SSH, VPN имеет другое предназначение. SSH разрабатывался как средство, позволяющее пользователю безопасно зайти и удалённо управлять другим компьютером. Цель VPN — прозрачный доступ к ресурсам сети, где пользователь может делать всё то, что он делает обычно независимо от того, насколько он удалён. По этой причине VPN приобрёл популярность среди дистанционных работников и офисов, которые нуждаются в совместном использовании ресурсов территориально разделённых сетей.

VPN Туннели

1. Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел
2. Оба узла требуют заранее настроеной политики, указывающей какие протоколы могут использоваться для шифрования и обеспечения целостности данных
3. Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается
4. Как только достигнуто соглашение по алгоритмам, создаётся ключ, который будет использован в симметричном алгоритме для шифрования/расшифровки данных

Есть несколько стандартов регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Т.к. IPSec — наиболее широко поддерживаемый стандарт, который имеет в арсенале наибольшее количество сокращений, оставшуюся часть статьи стоит посвятить именно ему.

CISCO vs HUAWEI IPSec VPN Configuration Comparison | Multiple IPSec VPN

IPSec

Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счёт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями. Т.к. IPSec — стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие RFC с http://www.rfc-editor.org/ могут оказаться полезными:

RFC 2401 IPSec RFC 2402 AH RFC 2406 ESP RFC 2409 IKE

Приведём краткое описание каждого, чтобы получить необходимую информацию для понимания следующей статьи, посвящённой настройке IPSec VPN на FreeBSD системе. Начнём с сокращений, а затем посмотрим как они укладываются в общую картину создания виртуальной частной сети.

AH (Authentication Header) — протокол заголовка идентификации. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC.

Huawei USG6000 Series: Site-to-site IPSec VPN Configuration

Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

ESP (Encapsulating Security Protocol) — инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.

Т.к. оба протокола — AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Если вспомнить статью TCP Protocol Layers Explained, то в ней сказано, что каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP — 17.

При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID — 51, а ESP имеет ID протокола равный 50. При создании правила не забывайте, что ID протокола не то же самое, что номер порта.

Третий протокол, используемый IPSec — это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное — не забудьте настроить правило на файрволе для UPD порта с номером 500, т.к. именно этот порт используется IKE.

SA (Security Association), что можно приближённо перевести как «связь или ассоциация безопасности» — это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаётся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA — это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

SA храняться в базе данных c названием, кто бы подумал — SAD (Security Association Database) или БД ассоциаций безопасности. Мы встретимся с ней ещё раз при настройке IPSec VPN.

Каждый узел IPSec также имеет вторую БД — SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Какие настройки включает в себя политика?

1. Симметричные алгоритмы для шифрования/расшифровки данных
2. Криптографические контрольные суммы для проверки целостности данных
3. Способ идентификации узла. Самые распространнённые способы — это предустановленные ключи (pre-shared secrets) или RSA сертификаты.
4. Использовать ли режим туннеля или режим транспорта
5. Какую использовать группу Diffie Hellman
6. Как часто проводить переидентификацию узла
7. Как часто менять ключ для шифрования данных
8. Использовать ли PFS
9. Использовать ли AH, ESP, или оба вместе

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройе VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.

Фаза Один и Фаза Два

Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга.

Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим — main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы — Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.

На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.

Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.

Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two — 60 минут. Для Phase One оно равно 24 часам.

Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдёт, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся.

Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке — это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовёт пересмотр соглашения между узлами с новыми настройками политики безопасности.

Теперь у нас есть достаточно информации для создания IPSec VPN на вашей FreeBSD машине. Демонстрация необходимых настроек — тема следующей статьи.

Dru Lavigne — инструктор Marketbridge Technologies в Оттаве и администратор Open Protocol Resource.

Copyright ╘ 2005 O’Reilly Media, Inc.

Источник: www.opennet.ru

Русские Блоги

Практическая настройка IPSEC_VPN (урок 3) — Установите lpl VPN-соединение ipsec между Huawei USG и Juniper SRX

1. Случай Введение

В этом примере описывается, как брандмауэры Huawei серии USG и брандмауэры серии Juniper SRX являются выходными пограничными устройствами общедоступной сети, и как установить двухточечное L2L VPN-соединение при наличии NAT.

2. Топология сети
Как показано на рисунке ниже, штаб-квартира (A) — это USG, а филиал (B) — это SRX в качестве примера.

(Рекомендуется поместить вышеуказанное изображение на черновик, отметить порт и IP для последующей настройки)

Сеть выглядит следующим образом:
• USG и SRX подключены к Интернету соответственно.
• Доступны маршруты общего доступа USG и SRX.
• USG и SRX — это фиксированные общедоступные сетевые адреса.
• USG и SRX являются шлюзами NAT.

Требования, которые должны быть выполнены, следующие:
• ПК1 и ПК2 могут иметь прямой доступ к публичной сети.
• Установите туннель IPSec между USG и SRX.
• Отделение ПК2 может безопасно общаться с головным ПК1.

Три, идеи конфигурации

1. Завершите базовую настройку интерфейса USG и SRX, политики безопасности, маршрутизации и так далее.
2. Полная настройка исходного NAT на USG и SRX. Терминалы ПК1 и ПК2 получают доступ к данным, которые могут выходить в Интернет после NAT.
3. Завершите настройку IPSec на USG и SRX. Потоки данных терминалов PC1 и PC2 через туннель IPSec не нужно преобразовывать с помощью NAT.

В-четвертых, этапы настройки
1. Базовая конфигурация оборудования
Базовая конфигурация межсетевого экрана USG штаб-квартиры
interface GigabitEthernet1/0/0
undo shutdown
ip address 111.11.11.11 255.255.255.240
service-manage ping permit
service-manage ssh permit
service-manage telnet permit
ipsec policy ipsec

interface GigabitEthernet1/0/1
undo shutdown
ip address 10.11.255.1 255.255.255.252
service-manage ping permit
service-manage ssh permit
service-manage telnet permit

ip route-static 0.0.0.0 0.0.0.0 111.11.11.1
ip route-static 10.1.1.0 255.255.255.0 10.11.255.2

Базовая конфигурация коммутатора в штаб-квартире
interface Ethernet0/0
no switchport
ip address 10.11.255.2 255.255.255.252
no shutdown
!
Vlan 110
!
interface Vlan110
ip address 10.1.1.1 255.255.255.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 10.11.255.1
!
Базовая конфигурация межсетевого экрана SRX филиала
set interfaces ge-0/0/0 unit 0 family inet address 222.22.22.18/28
set interfaces ge-0/0/1 unit 0 family inet address 10.22.255.1/30
set routing-options static route 10.2.2.0/24 next-hop 10.22.255.2
set routing-options static route 0.0.0.0/0 next-hop 222.22.22.17
Базовая конфигурация отраслевых коммутаторов
interface Ethernet0/0
no switchport
ip address 10.22.255.2 255.255.255.252
no shutdown
!
vlan 10
!
interface Vlan10
ip address 10.2.2.1 255.255.255.0
no shutdown
!
interface Ethernet0/1
switchport access vlan 10
switchport mode access
no shutdown
!

2. Настройка NAT
Настройка NAT межсетевого экрана USG штаб-квартиры
ip address-set mappd_add type object
address 0 10.1.1.0 mask 24

security-policy
default action permit
quit

rule name to_public
source-zone trust
destination-zone untrust
source-address address-set mappd_add
action nat easy-ip

Пингуйте общедоступный сетевой адрес на коммутаторе.
, как показано ниже:

На брандмауэре USG вы видите, что внутренний сетевой адрес был преобразован в общедоступный сетевой адрес.
, как показано ниже:

Настройка NAT межсетевого экрана SRX филиала
set security nat source rule-set trust-to-untrust from zone trust
set security nat source rule-set trust-to-untrust to zone untrust
set security nat source rule-set trust-to-untrust rule source-nat-rule match source-address 0.0.0.0/0
set security nat source rule-set trust-to-untrust rule source-nat-rule then source-nat interface

Пингуйте общедоступный сетевой адрес на коммутаторе филиала.
, как показано ниже:

3. Конфигурация VPN
Конфигурация VPN межсетевого экрана USG штаб-квартиры
①, настройте предложение безопасности IPSec. Параметры по умолчанию могут быть не настроены.
ipsec proposal srx
esp authentication-algorithm md5
esp encryption-algorithm des
Conf. Настройте предложение безопасности IKE. Параметры по умолчанию могут быть не настроены.
ike proposal 10
encryption-algorithm 3des
dh group2
authentication-algorithm sha1
authentication-method pre-share
integrity-algorithm hmac-sha1-96
prf hmac-sha1
③, настройте узел IKE.
ike peer srx
pre-shared-key [email protected]
ike-proposal 10
remote-address 222.22.22.18
Def. Определите защищенный поток данных.
Настройте расширенный ACL 3001, чтобы разрешить сегменту сети 10.1.1.0/24 доступ к сегменту сети 10.1.2.0/24.
acl number 3001
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255
⑤, настройте политику IPSec.
ipsec policy ipsec 10 isakmp
security acl 3001
ike-peer srx
proposal srx
sa trigger-mode auto
sa duration traffic-based 5242880
App. Примените группу политик IPSec ipsec на интерфейсе GE1 / 0/0.
interface GigabitEthernet 1/0/0
ipsec policy ipsec
Конфигурация VPN межсетевого экрана филиала SRX
①, настройте IKE
set security ike proposal l2l authentication-method pre-shared-keys
set security ike proposal l2l dh-group group2
set security ike proposal l2l authentication-algorithm sha1
set security ike proposal l2l encryption-algorithm 3des-cbc
set security ike proposal l2l lifetime-seconds 86400
set security ike policy l2l mode main
set security ike policy l2l proposals l2l
set security ike policy l2l pre-shared-key ascii-text [email protected]
set security ike gateway l2l ike-policy l2l
set security ike gateway l2l address 111.11.11.11
set security ike gateway l2l external-interface ge-0/0/0.0
set security ike gateway l2l version v1-only
②, настройте IPSec
set security ipsec proposal trans1 protocol esp
set security ipsec proposal trans1 authentication-algorithm hmac-md5-96
set security ipsec proposal trans1 encryption-algorithm des-cbc
set security ipsec proposal trans1 lifetime-seconds 3600
set security ipsec policy l2l proposals trans1
set security ipsec vpn l2l ike gateway l2l
set security ipsec vpn l2l ike ipsec-policy l2l
set security ipsec vpn l2l establish-tunnels immediately
③, определите интересующий вас поток
set security zones security-zone trust address-book address local-address01 10.2.2.0/24
set security zones security-zone untrust address-book address remote-address01 10.1.1.0/24
④, стратегическое направление связано с VPN
set security policies from-zone trust to-zone untrust policy l2l01 match source-address local-address01
set security policies from-zone trust to-zone untrust policy l2l01 match destination-address remote-address01
set security policies from-zone trust to-zone untrust policy l2l01 match application any
set security policies from-zone trust to-zone untrust policy l2l01 then permit tunnel ipsec-vpn l2l
set security policies from-zone untrust to-zone trust policy l2l01 match source-address remote-address01
set security policies from-zone untrust to-zone trust policy l2l01 match destination-address local-address01
set security policies from-zone untrust to-zone trust policy l2l01 match application any
set security policies from-zone untrust to-zone trust policy l2l01 then permit tunnel ipsec-vpn l2l

5. Проверка результатов
1. Инициируйте операцию ping
Инициируйте операцию ping с адресом шлюза на коммутаторах на стороне USG и SRX.
, как показано ниже:

2. Просмотр информации о VPN
На брандмауэре SRX видно, что IKE успешно согласован и IPSec успешно установлен.
, как показано ниже:

Точно так же соответствующую информацию IKE можно также увидеть на брандмауэре USG.
, как показано ниже:

6. Информация об оборудовании
В этом эксперименте
Версия устройства SRX: версия 12.1X47-D20.7
Версия устройства USG: версия 5.160
Версия коммутируемого устройства: никаких особых требований, только поддержка трех уровней

Источник: russianblogs.com

IPSec VPN

IPSec is a protocol suite defined by the Internet Engineering Task Force (IETF) for securing IP communication by authenticating and encrypting each IP packet of a communication session. Two communicating parties can encrypt data and authenticate the data origin at the IP layer to ensure data confidentiality and integrity and prevent replay of data packets.

IPSec uses two security protocols: Authentication Header (AH) protocol and Encapsulating Security Payload (ESP). Key exchange and SA establishment in IPSec is implemented by the IKE protocol, which simplifies use and management of IPSec.

IPSec Security Protocol

AH defines the authentication method and checks data integrity and data origin. ESP defines the encryption and authentication methods and ensures data reliability.

• AH: provides data origin authentication, data integrity check, and the anti-replay service. The sender performs hash calculation on the IP payload and all header fields of an IP packet except for variable fields to generate a message digest. The receiver calculates a message digest according to the received IP packet and compares the two message digests to determine whether the IP packet has been modified during transmission. AH does not encrypt the IP payload.
• ESP: encrypts the IP payload in addition to providing all the functions of AH. ESP can encrypt and authenticate the IP payload but does not authenticate the IP packet header.

IPSec Peer

IPSec provides secure IP communication between two endpoints. The two endpoints are called IPSec peers.

Security Association (SA)

A security association (SA) is a set of algorithms such as the encryption algorithm and parameters such as keys for secure data transmission between IPSec peers.

• Transport mode: inserts an IPSec header between the IP header and the header of the upper-layer protocol (AH or ESP). In this mode, the protocol type field in the IP header is changed to AH or ESP, and the checksum in the IP header is recalculated. The transport mode applies to communication between two hosts or between a host and a security gateway.
• Tunnel mode: encapsulates an IPSec header (AH or ESP) on the original IP header and adds a new IP header. In this mode, the original IP packet is transmitted as the payload of the packet and is protected by IPSec. The tunnel mode applies to communication between two security gateways. Packets encrypted by one security gateway must be decrypted by the other security gateway.

• IPSec uses the Message Digest 5 (MD5) algorithm, Secure Hash Algorithm (SHA-1) or Secure Hash Algorithm (SHA-2) for authentication. The MD5 algorithm computes faster than the SHA-1 algorithm, but the SHA-1 algorithm is more secure than the MD5 algorithm. SHA-2 increases the number of encrypted data bits and is more secure than SHA-1.
• IPSec uses the DES, Triple Data Encryption Standard (3DES), or Advanced Encryption Standard (AES) algorithm for encryption. The AES algorithm encrypts plain text by using a key of 128 bits, 192 bits, or 256 bits.

Establishing an IPSec Tunnel Using IKE Negotiation

IKE

IKE builds upon the Internet Security Association and Key Management Protocol (ISAKMP) and provides the key negotiation, identity authentication, and SA establishment functions to simplify IPSec use and management.

IKE Version

• IKEv1: defines two phases for IPSec key negotiation. IKEv1 phase 1 operates in either main mode or aggressive mode. The aggressive mode allows two IPSec peers to establish an IKE SA more quickly than in main mode. In main mode, only IP addresses can be used to identify IPSec peers. In aggressive mode, both IP addresses and names can be used to identify IPSec peers.
• IKEv2: defines three types of exchanges and enables two IPSec peers to establish an IKE SA more quickly than IKEv1.

• Diffie-Hellman (DH) algorithm: DH algorithm is a public key algorithm. The two communicating parties do not transmit a key but exchange data to calculate a shared key. They use the calculated shared key to encrypt data and exchange the encrypted data. IKE-enabled devices never directly transmit a key on an insecure network. Instead, the devices calculate a shared key by exchanging data. Even though a third party (such as a hacker) intercepts all exchanged data for key calculation, it cannot calculate the actual key.
• Perfect Forward Secrecy (PFS): PFS is a property that prevents other keys from being decoded when one key is decoded. The key used in IPSec phase 2 is derived from the key used in IPSec phase 1. After intercepting the key used in phase 1, an attacker may collect enough information to calculate the key to be used in phase 2. PFS provides an additional DH key exchange to secure the key used in phase 2.
• Identity authentication: authenticates identities of the two communicating parties including pre-shared key authentication and digital certificate authentication. In pre-shared key authentication, two communicating parties use a shared key to calculate a digest for a received packet and compare the digest with the digest field in the packet. If the calculated digest is the same as that in the packet, authentication succeeds; otherwise, authentication fails. In digital certificate authentication, two communicating parities use an agreed algorithm to calculate the digest for a packet. The sender uses its own private key to encrypt the digest field and generates a digital signature. The receiver uses the sender’s public key to decrypt the digital signature and compares the calculated digest with the original digest field. If the calculated digest is the same as the original digest of the packet, authentication succeeds; otherwise, authentication fails.

Establishing an IPSec Tunnel Using an IPSec Virtual Tunnel Interface

An IPSec virtual tunnel interface is a Layer 3 logical interface supporting dynamic routing protocols. All packets passing through the IPSec virtual tunnel interface are protected by IPSec.

After an IPSec tunnel is established using an IPSec virtual tunnel interface, data flows routed to the IPSec virtual tunnel interface are protected by IPSec. Compared to using an ACL to determine data flows to be protected, using routing to determine the flows to be protected simplifies the IPSec policy deployment and prevents IPSec configuration from being affected by the network plan. This enhances network scalability and reduces network maintenance costs.

Establishing an IPSec Tunnel Using An Efficient VPN Policy

Efficient VPN

IPSec Efficient VPN has high security, reliability, and flexibility and has become the first choice for enterprises to establish VPNs. When establishing an IPSec tunnel between a branch and headquarters, an enterprise must configure IPSec and other network resources on the branch. If the network has hundreds of sites, IPSec configurations are complex and network maintenance is difficult.

The Efficient VPN solution integrates IPSec and other configurations on the Efficient VPN server. When basic parameters for establishing an SA are configured on the remote device, the remote device initiates a negotiation with the server and establishes an IPSec tunnel. After the IPSec tunnel is established, the server allocates other IPSec attributes and network resources to the remote device. Efficient VPN simplifies configurations and maintenance of IPSec and network resources for the branches.

• Client mode: A remote device configured with IPSec Efficient VPN connects to the headquarters and automatically applies to the server for an IP address and other network resources such as DNS domain, DNS server address, WINS server address, and delivered ACL resources. The remote device allocates these resources to PCs at the remote end using DHCP. The remote device automatically enables NAT. When receiving a packet from a PC on the remote subnet, the remote device translates the source IP address of the packet matching the pushed ACL resources and sends the packet to the server through an IPSec tunnel. Packets that do not match the pushed ACL resources are not translated by NAT and are not allowed to pass through the IPSec tunnel. These packets are forwarded to the Internet.
• Network mode: Unlike the client mode, IP addresses of branches and headquarters are configured beforehand in network mode. The remote device does not apply to the server for an IP address or enable NAT.
• Network-plus mode: The network-plus mode is a combination of the network mode and client mode. IP addresses of branches and headquarters are configured beforehand. The remote device applies to the server for an IP address. The server uses the IP address to perform ping, Telnet mode, or other management and maintenance operations. NAT is not performed on packets to be protected.

Efficient VPN License

The Efficient VPN function is used with a license. To use the Efficient VPN function, apply for and purchase the following license from the Huawei local office:

The AR100AR160160https://support.huawei.com/enterprise/en/doc/EDOC1100033775/c11c5416/ipsec-vpn» target=»_blank»]support.huawei.com[/mask_link]