Juniper SSG5 VPN (Virtual Private Network)設定
VPN (Virtual Private Network)設定
什麼是VPN ?
VPN 是 Virtual Private Network (虛擬私有網路) 的縮寫，是一種利用公眾網路建立一個經過加密的虛擬通道，而這個通道是一個安全、方便又經濟的私有通道。我們常常要透過網際網路來傳輸資料，但是在Internet傳輸的資料會有被駭客截取資料的風險，特別是在高科技公司、政府機關或是軍方單位等機構更是有這樣的風險，一般的做法是跟電信公司申請一條專線，只提供給內部人員來使用，唯此法費用高昂，只有公司行號與政府機構等單位才能負擔，況且若是台灣公司要與美國分公司之間建立專線，則困難度又太高，於是使用VPN來替代專線，似乎是較為可行的方案。
而使用VPN的目的是讓兩台位於不同地點的網路設備(例如總公司與分公司)，透過網際網路建立一個經過加密的虛擬通道，這條通道是外人無法使用，只提供給內部人員使用，在使用上就好像是在公司內部的區域網路一般方便與安全(這比拉一條專線然後每個月要付幾萬元的費用還要來得經濟)。而企業也可透過這個安全通道讓出差在外的辦公人員可以從遠端撥入VPN通道來讀取公司內部的資料。
那VPN又要如何來達到這個目的呢？原理是設備將要傳輸的資料經過嚴格加密後再來傳輸，而您若沒有解密金鑰，則要將資料解密會變得非常困難，甚至要花上數十年的時間才行。而方法是兩台要建立VPN通道的網路設備，透過驗證或認證的機制來彼此相互協商，並對協商內容及資料傳輸內容進行嚴格的加密的動作，以確保在網際網路傳輸資料的安全。
下圖為網際網路VPN拓墣圖。
IPsec VPN有兩種設定方式，分別是Route-Based IPsec VPN 和 Policy-Based IPsec
VPN。
而到底何時要用Route-Based VPN，何時該用Policy-Based VPN呢?
以下為Juniper官方網站對IPsec VPN的介紹與描述：
Understanding Policy-Based IPsec VPNs
瞭解基於策略的IPsec
VPN
For policy-based
IPsec VPNs，a security policy specifies as its action the VPN tunnel to be used for
transit traffic that meets the policy’s match criteria. A VPN is configured
independent of a policy statement. The policy statement refers to the VPN by
name to specify the traffic that is allowed access to the tunnel. For
policy-based VPNs，each policy creates an individual IPsec security association (SA) with the
remote peer，each of which counts as an individual VPN tunnel. For example，if a
policy contains a group source address and a group destination address，whenever
one of the users belonging to the address set attempts to communicate with any
one of the hosts specified as the destination address，a new
tunnel is negotiated and established. Because each tunnel requires its own
negotiation process and separate pair of SAs，the use of policy-based IPsec VPNs can be more
resource-intensive than route-based VPNs.
對於基於策略的IPsec VPN,安全性原則將其操作指定為用於傳輸通信並符合策略的匹配條件的VPN隧道。VPN是獨立于策略語句配置的。策略敘述語句通過引用VPN的名稱來指定允許訪問隧道的通信量。對於基於策略的VPN，每個策略都與遠端對等方建立一個的單獨的IPsec SA，每個IPsec SA都是一個單獨的VPN隧道。例如，如果策略包含來源位址群組(group
source address)和目標位址群組(group destination
address)，則每當屬於該位址集的使用者之一嘗試與指定為目標位址的任何一個主機通信時，就會協商並建立新的隧道,由於每個隧道都需要自己的協商過程和獨立的一對SA,因此,使用基於策略的IPsec VPN可能比使用基於路由的VPN更耗費資源。
Understanding Route-Based IPsec VPNs
瞭解基於路由的IPsec VPN
With route-based VPNs，you can
configure dozens of security policies to regulate traffic flowing through a
single VPN tunnel between two sites，and there is just one set of IKE and IPsec SAs at
work. Unlike policy-based VPNs，for route-based VPNs，a policy refers to a destination address，not a VPN tunnel. When Junos OS looks up a route to
find the interface to use to send traffic to the packet’s destination address，it finds a
route through a secure tunnel interface (st0.x). The tunnel interface is
bound to a specific VPN tunnel，and the traffic is routed to the tunnel if the policy action is permit.
對於基於路由的VPN,您可以配置數十種安全性原則並透過兩個網站之間的單個VPN隧道來調節交通流量，並且在工作時只有一組 IKE 和 IPsec sa。與基於策略的VPN不同，對於基於路由的VPN，策略指的是目標位址，而不是VPN隧道。當Junos OS查找路由以找到用於向資料包的目標位址發送通信的介面時,它通過安全的隧道介面(st0.x)找到路由。這個隧道介面會和特定的VPN隧道綁定，並且如果策略允許的話則會將通信傳送到隧道。
Understanding
Route-Based and Policy-Based IPsec VPNs
瞭解基於路由和基於策略的IPsec
VPN
With route-based VPNs，you can configure dozens of security policies to
regulate traffic flowing through a single VPN tunnel between two sites，and there
is just one set of IKE and IPsec SAs at work. Unlike policy-based VPNs，for
route-based VPNs，a policy refers to a destination address，not a VPN tunnel. When Junos OS looks up a route
to find the interface to use to send traffic to the packet’s destination
address，it finds a route through a secure tunnel interface (st0.x). The
tunnel interface is bound to a specific VPN tunnel，and the
traffic is routed to the tunnel if the policy action is permit.
對於基於路由的vpn，您可以配置數十種安全性原則並透過兩個網站之間的單個VPN隧道來調節交通流量，並且只需要一組IKE和IPsec SA即可工作。不同於基於策略的VPN，對於基於路由的VPN,策略參考的是目標位址，而不是VPN隧道。當Junos OS查找路由以找到向的目標位址發送通信資料包的介面時,它會找到一條經過安全的隧道介面(st0.x)的路由。這個隧道介面會和特定的VPN隧道綁定，並且如果策略允許的話則會將通信傳送到隧道。
Route-based vs Policy-based VPN
With policy-based VPN tunnels，a tunnel is treated as an object that
together with source，destination，application，and action，comprises a
tunnel policy that permits VPN traffic. In a policy-based VPN configuration，a tunnel policy specifically references a VPN
tunnel by name.
使用基於策略的 vpn 隧道，隧道被視為與來源、目標、應用程式和操作一起使用的物件，它包括允許 vpn 通信的隧道策略。在基於策略的 vpn 配置中，隧道策略通過名稱專門引用 vpn 隧道。
使用基於策略的 vpn 隧道，隧道被視為與來源、目標、應用程式和操作一起使用的物件，它包括允許 vpn 通信的隧道策略。在基於策略的 vpn 配置中，隧道策略通過名稱專門引用 vpn 隧道。
With route-based VPNs，a policy does not specifically reference a
VPN tunnel. Instead，the policy
references a destination address. When the security device does a route lookup
to find the interface through which it must send traffic to reach that address，it finds a route via a secure tunnel (ST)
interface，which is bound to a
specific VPN tunnel.
使用基於路由的vpn，策略不專門引用 vpn 隧道。相反，該策略引用目標位址。當安全設備進行路由查找以找到必須通過其發送通信以到達該位址的介面時，它將通過安全隧道 (ST) 介面找到路由，綁定到特定的 VPN 隧道。
使用基於路由的vpn，策略不專門引用 vpn 隧道。相反，該策略引用目標位址。當安全設備進行路由查找以找到必須通過其發送通信以到達該位址的介面時，它將通過安全隧道 (ST) 介面找到路由，綁定到特定的 VPN 隧道。
Thus，with a
policy-based VPN tunnel，you can
consider a tunnel as an element in the construction of a policy. With a
route-based VPN tunnel，you can
consider a tunnel as a means for delivering traffic，and the policy as a method for either permitting or denying the
delivery of that traffic.
因此,使用基於策略的VPN隧道，您可以將隧道視為構建策略的元素。使用基於路由的VPN隧道,您可以將隧道視為提供通信的一種方法,而該策略可作為允許或拒絕傳輸該通信量的方式。
The following are reasons why you implement
route-based VPN:
- Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
- There are overlapping subnets or IP addresses between the two LANs.
- Hub-and-spoke VPN topology is used in the network.
- Primary and backup VPN are required.
- A dynamic routing protocol (for example，OSPF，RIP，or BGP) is running across the VPN.
- Multiple subnets or networks at the remote site across the VPN need to be accessed.
以下是實施基於路由的VPN的原因:
·在通過VPN傳輸時需要啟用來源或目標nat(nat-src或nat)。
·兩個lan之間存在重疊的子網或 IP 位址。
·在網路中使用了中心和分支(集中星型)的VPN拓撲。
·當需要主要VPN和備援VPN時。
·在VPN 中運行動態路由式通訊協定 (例如，OSPF、RIP 或 BGP)。
·需要訪問跨VPN的遠端站台上的多個子網或網路。
The following are reasons why you
implement policy-based VPN:
- The remote VPN device is a non-Juniper device that requires separate SAs for each remote subnet.
- You are implementing a dial-up VPN.
- Only one subnet or one network at the remote site across the VPN needs to be accessed.
- You require more granularity than a route can provide when determining which traffic is sent to a tunnel (for example，you need to specify that traffic
to a
certain destination goes through the tunnel only if the traffic originated from
a particular source).
以下是實施基於策略的VPN的原因:
- 遠端VPN設備是一種非瞻博(non-Juniper)設備且每個遠端子網都需要單獨的SA。
- 您正在實施撥號 VPN。
- 在VPN上的遠端站台上只需要訪問一個子網或一個網路。
- 在偵測決定要將哪些通信流發送到隧道時,您需要的細微性比路由所能提供的要多時(例如,您需要指定只有當通信來自特定來源時,才能通過隧道進行通信)。
Note: We
recommend that you use route-based VPN when you want to configure VPN between
multiple remote sites. Route-based VPN allows for routing between the spokes
between multiple remote sites; it is easier to configure, monitor, and
troubleshoot.
注意: 我們建議您在需要在多個遠端站台之間配置 vpn 時使用基於路由的vpn。基於路由的VPN允許在多個遠端站台相互彼此之間進行路由;它更易於被配置、監控和故障排除。
Use policy-based VPN when your topology has a third-party
device and requires a separate SAs for each remote subnet.
當拓撲具有其他廠牌(third-party)的設備，並且每個遠端子網都需要單獨的SAs時，請使用基於策略的VPN。
Note: Configuring RIP demand circuits over
point-to-multipoint VPN interfaces is not supported.
注意: 不支援在一對多VPN介面上配置
RIP 需求電路。
Note: A secure tunnel (st0) interface
supports only one IPv4 address and one IPv6 address at the same time. This
applies to all route-based VPNs. The disable option is not supported on st0
interfaces.
注意: 安全隧道(st0)介面同時只支援一個IPv4位址和一個IPv6位址。這適用于所有基於路由的VPN。st0介面不支援禁用選項。
IPsec VPN 拓撲
以下是Junos 作業系統(OS)
支援的部分IPsec VPN 拓撲：
網站到網站VPN—將組織中的兩個網站連接起來，並允許網站間安全通信。
集中星型VPN—在企業網路中將分支機搆連接到公司辦公室。還可以利用此拓撲通過經集線器發送資訊流來將末端連接起來。
遠端存取VPN—允許在家工作或差旅途中的用戶連接至公司辦公室及其資源。此拓撲有時稱為end-to-site
tunnel。
IPSec是如何工作的?
IPSec 涉及許多元件技術和加密方法。然而，IPSec 的操作可以分解為五主要步驟:
1. "有趣的流量interesting traffic " 啟動 IPSec 進程。當 ipsec 對等方中配置的 ipsec 安全性原則啟動 IKE 進程時，通信被認為是有趣的。
2. IKE 階段1。IKE
(Internet Key Exchange)在這一階段對ipsec對等方進行身份驗證並協商IKE SA (ISAKMP SA)，為在階段2中協商的ipsec sa建立一個安全通道，簡單的說Phase 1 的工作就是為 Phase 2 準備一條加密管道，讓 Phase 2
用這條管道去交換資訊。
3. IKE 階段2。IKE 協商 ipsec sa 參數，並在對等方中設置匹配的 ipsec sa。
4. 資料傳輸。根據存儲在 SA 資料庫中的 ipsec 參數和金鑰，在 ipsec 對等方之間傳輸資料。
5. IPSec 隧道終止。IPSec sa 通過刪除或超時來終止。
IPsec 連接的建立在兩個階段發生，稱為 IKE 階段:
步驟 2-IKE 階段1(IKE Phase 1)
IKE 階段1的基本目的是對 IPSec
對等方進行身份驗證，並在對等方之間設置安全通道以啟用 IKE 交換。
什麼是身份驗證呢？很簡單，我是 Site A 的 Router，您說您是 Site B 的 Router 想和我建立 VPN，我怎知道您真的是 Site B 而不是其他公司呢？其中一個常用的方法是用 Share Secret 來認證，即是說 Site A 和 Site B 的 Router 都知道同一組密碼，證明是自己人，就通過認證了。
另外，Phase
1 還會用透過 Diffie-Hellman 來建立一組 Key，這組 Key 是用來為
Phase 2 的資訊進行加密。
ike 階段1建立了一個 ISAKMP
sa (通常稱為 ike sa)。如果 IKE 階段1協商成功，則建立 ISAKMP SA。ISAKMP
SA 實質上包含了協商的 "中標方案" 中的資訊，記錄了成功協商的安全加密和金鑰材料。這將創建一個安全的 "控制通道"，其中保留了用於保護2階段協商的金鑰和其他資訊。ISAKMP SA 只加密階段 2 ESP SA協商，以及兩個端點之間的任何 IKE 消息。
以下敘述為原廠"ScreenOS"參考指南 中節錄下來的內容：
階段 1
「自動金鑰 IKE」通道交涉的「階段
1」由如何驗證和保護通道的提議交換組成。
交換可以在兩種模式的其中一種中進行: 挑釁式模式或主要模式。使用任一種模式時，參與者會交換可接受的安全性服務提議，例如:
加密演算法 (DES 和 3DES) 和驗證演算法 (MD5 和 SHA-1)。
Diffie-Hellman 群組。
預先共享金鑰或 RSA/DSA 認證。
當通道的兩端都同意接受所提出的至少一組「階段
1」安全參數，並處理參數時，就結束一個成功的「階段 1」交涉。Juniper Networks 安全性裝置最多支援四個「階段 1」交涉的提議(Proposal)，讓您可以定義對一系列安全性參數的限制程度，以便接受金鑰交涉。
ScreenOS
提供的預先定義「階段 1」提議如下(在JUNOS上也相同)：
標準: pre-g2-aes128-sha 和 pre-g2-3des-sha
相容: pre-g2-3des-sha、pre-g2-3des-md5、pre-g2-des-sha 和 pre-g2-des-md5
基本: pre-g1-des-sha 和 pre-g1-des-md5
也可以定義自訂的「階段
1」提議。
ps：從上述內容我們可以看出，預先定義的提議"標準"加密演算法使用aes128-sha，而"相容"則不包含aes128-sha(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
而Juniper JUNOS除了上述三種預先定義「階段 1」提議之外，還有其他四種預先定義的「階段 1」提議，全部列示如下：
proposal-set (standard | compatible | basic | prime-128 | prime-256
| suiteb-gcm-128 | suiteb-gcm-256);
其說明我們可以參考原廠連結： proposal-set(Security IKE)
主要模式和挑釁式模式
「階段 1」可能發生在主要模式或挑釁式模式中。這兩種模式的描述如下。
主要模式(Main Mode): 初始程式和接受方傳送三個雙向交換
( 總共六條訊息) 以完成下列服務:
第一次交換 ( 訊息 1 和 2): 提議並接受加密和驗證演算法。
第二次交換 ( 訊息 3 和 4): 執行 Diffie-Hellman 交換，初始程式和接受方各提供一個偽隨機號碼。
第三次交換 ( 訊息 5 和 6): 傳送並確認身份。
在第三次交換訊息時傳輸的資訊由在前兩次交換中建立的加密演算法保護。因此，在純文字中沒有傳輸參與者的身份。
挑釁式模式(Aggressive Mode): 又稱做挑戰模式，初始程式和接受方到達相同的物件，但僅進行兩次交換，總共有三條訊息:
第 1 條訊息: 初始程式提議 SA、初始化 Diffie-Hellman 交換，並傳送一個偽隨機號碼及其 IKE 身份。
第 2 條訊息: 接受方接受 SA、驗證初始程式，並傳送一個偽隨機號碼及其
IKE身份，以及傳送接受方的認證 ( 如果使用認證)。
第 3 條訊息: 初始程式驗證接受方、確認交換，並傳送初始程式的認證
(如果使用認證)。
由於參與者的身份是在純文字中交換的
( 在前兩條訊息中)，所以挑釁式模式不提供身份保護。
注意: 當撥接 VPN 使用者使用預先定義的金鑰交涉「自動金鑰
IKE」通道時，必需使用挑釁式模式。也請注意撥接 VPN 使用者也可以使用電子郵件位址、完全合格的網域名稱 (FQDN) 或 IP 位址作為其 IKE ID。動態對等方可以使用電子郵件位址或FQDN，但不可以使用 IP 位址。
Diffie-Hellman 交換
Diffie-Hellman (DH) 交換允許參與者產生一個共享的秘密值。該技術的優點在於它允許參與者在未保全的媒體上建立秘密值，而不把此秘密值透過網線傳遞。有五個Diffie-Hellman 群組；ScreenOS 支援群組 1、2 和 5。在各群組的計算中所使用主要模數的大小都有差異，如下所述:
DH 群組 1: 768 位元模數
DH 群組 2: 1024 位元模數
DH 群組 5: 1536 位元模數
注意: 「DH 組 1」安全性的強度已經降低，我們不建議使用。
一般認為模數越大，產生的金鑰就越安全；但是，模數越大，金鑰產生過程就越長。由於每個 DH 群組的模數大小都不同，因此參與者必需同意使用相同的群組。
注意: 如果組態多個 ( 最多四個) 「階段 1」交涉提議(Proposals)，請在所有的提議中使用相同的Diffie-Hellman 群組。同樣的準則可套用到「階段 2」交涉的多個提議。
而Juniper SRX JUNOS支援的Diffie-Hellman群組較多，總共以下七組：
·
DH Group 1—768-bit modulus
·
DH Group 2—1024-bit modulus
·
DH Group 5—1536-bit modulus
·
DH Group 14—2048-bit modulus
·
DH Group 19—256-bit modulus
elliptic curve
·
DH Group 20—384-bit modulus
elliptic curve
·
DH Group 24—2048-bit modulus
with 256-bit prime order subgroup
Note:
We do not recommend the use of DH groups 1, 2, and 5.
步驟 3-IKE 階段2(IKE Phase 2)
IKE 階段2的目的是協商 ipsec
sa 以設置 ipsec 隧道。
在 IKE 階段2中，兩個端點使用在1階段中創建的安全隧道來協商 ESP sa。ESP sa 是用來對兩個端點之間傳遞的實際使用者資料進行加密的。
ike 階段2的協商也由 ike 協定管理。使用SA提供的加密，安全性原則用於嘗試和協商階段2 SA。安全性原則包括有關通信主機和子網的資訊，以及用於為連接提供安全服務的 ESP 資訊，如加密密碼和雜湊演算法。如果 IKE 階段2協商過程成功，則會在兩個端點之間建立一對 ESP sa (通常稱為 IPsec sa)，即一個入站和一個出站。這是兩個端點之間的加密 VPN "隧道"。此時，使用者資料可以通過加密的隧道進行交換。
以下敘述為原廠"ScreenOS參考指南" 中節錄下來的內容：
階段 2
當參與者建立了一個已驗證的安全通道後，會繼續執行「階段
2」，在此階段中，他們將交涉 SA 以保護要透過 IPSec 通道傳輸的資料。
與「階段 1」的過程相似，參與者交換提議以確定要在
SA 中應用的安全參數。
「階段 2」提議也包括一個安全性通訊協定
(「封裝安全性負載 (ESP)」或「驗證標頭 (AH)」) 和選擇的加密和驗證演算法。如果需要「完美轉送安全性
(PFS)」，提議中還可以指定一個 Diffie-Hellman 群組。
不管在「階段 1」中使用何種模式，「階段
2」總是在「快速」模式中執行，並且包括三條訊息的交換。
Juniper Networks 安全性裝置最多支援四個「階段
2」交涉的提議，讓您可以定義對一系列通道參數的限制程度，以便接受它們。ScreenOS 也提供重播保護功能。
使用此功能不需要交涉，因為封包一定會和序號一起傳送。您只能選擇要不要檢查序號。( 有關重播保護的詳細資訊，請參閱第10 頁上的「重播保護」。)
ScreenOS
提供的預先定義「階段 2」提議如下(在JUNOS上也相同):
標準: g2-esp-3des-sha 和 g2-esp-aes128-sha
相容: nopfs-esp-3des-sha、nopfs-esp-3des-md5、nopfs-esp-des-sha 和nopfs-esp-des-md5
基本: nopfs-esp-des-sha 和 nopfs-esp-des-md5
也可以定義自訂的「階段
2」提議。
ps：從上述內容我們可以看出，預先定義的提議"標準"包含有DH Group，而"相容"則不包含DH Group(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
而Juniper JUNOS除了上述三種預先定義「階段 2」提議之外，還有其他四種預先定義的「階段 2」提議，全部列示如下：
proposal-set (standard | compatible | basic | prime-128 | prime-256
| suiteb-gcm-128 | suiteb-gcm-256);
其說明我們可以參考原廠連結： proposal-set(Security IPsec)
Proxy IDs
在「階段 2」中，對等方也交換
proxy ID。proxy ID 是一個三部份組合，由本機
IP位址、遠端 IP 位址和服務組成。兩個對等方的 proxy ID 必需配對，這意味著兩個對等方的
proxy ID 中指定的服務必需相同，並且為一個對等方指定的本機 IP 位址必需與為另一個對等方指定的遠端
IP 位址相同。
完美轉送安全性(PFS - Perfect
Forward Secrecy)
「完美轉送安全性 (PFS)」是一種用於衍生「階段
2」金鑰的方法，與前述金鑰無關。此外，「階段 1」提議會建立金鑰 (SKEYID_d 金鑰)，從其中將衍生所有的「階段
2」金鑰。SKEYID_d 金鑰可以用最低的 CPU 處理產生「階段 2」金鑰。
不巧的是，如果某個未授權方得到
SKEYID_d 金鑰的存取權，將洩漏所有的加密金鑰。
PFS 透過對每個「階段 2」通道強制產生新的
Diffie-Hellman 金鑰交換來解決此安全風險。雖然在啟用 PFS 後，「階段 2」中的重新建立金鑰過程可能需要稍微更長
的時間，但使用 PFS 比較安全。
重播保護(Replay Protection)
當有人截取一系列封包並稍後使用封包大量攻擊系統、導致服務中斷
(DoS) 或進入受信任的網路時會發生重播攻擊。重播保護功能會讓安全性裝置檢查每一個 IPSec封包，以檢視以前是否接收過此封包。如果封包到達時在指定的序列範圍外，安全性裝置會拒絕封包。
步驟 4-IPSec 加密隧道
IKE 階段2完成後，快速模式建立了 ipsec sa，資訊通過 ipsec 隧道進行交換。使用 IPSec SA 中指定的加密對資料包進行加密和解密。
通常配置VPN的前提有兩個：
一、兩端的設備都能夠分別訪問到遠端的外網介面。
最簡單的方式就是PING遠端的外網介面，若對方關閉了對PING回應的功能，則只能在連線時根據LOG紀錄來判斷了。
二、對於IPSec的VPN而言，兩端設備之間的防火牆要開放讓UDP埠為500的資料包通過。
下列連結及資料乃是在Juniper官方網站上找到的：
Internet Protocol Security (IPSec) uses IP
protocol 50 for Encapsulated Security Protocol (ESP)，IP protocol 51 for Authentication Header (AH)，and UDP port 500 for IKE Phase 1 negotiation and Phase 2 negotiations.
UDP ports 500 and 4500 are used，if NAT-T is
used for IKE Phase 1 negotiation and Phase 2 negotiations
Secure Sockets Layer (SSL) uses TCP port 443 and
works by using a private key to encrypt data that is transferred over the SSL
connection. SSL also uses 465 Secure SMTP，993 Secure
IMAP，and 995 Secure POP.
Layer Two Tunneling Protocol (L2TP) uses TCP
port 1701 and is an extension of the Point-to-Point Tunneling Protocol. L2TP is
often used with
IPSec to establish a Virtual Private Network (VPN).
Point-to-Point
Tunneling Protocol (PPTP) uses TCP port 1723 and IP port 47 Generic Routing Encapsulation
(GRE). PPTP provides a low-cost，private connection to a corporate
network through the Internet. PPTP works well for people who work from home or
travel and need to access their corporate networks. It is often used to access
a Microsoft Remote Access Server (RAS)
上述內容為各種vpn會使用到的port numbers，其中關於L2TP的部分要補充說明，由於L2TP 協定使用時常常會跟IPSec一起使用(L2TP Over IPSec)，所以我們就要將L2TP的Ports與IPSec的Ports一併開放才行。
在開始設定VPN之前，請先讓兩端設備先做好網路對時的作業，以避免兩台設備LOG日誌記錄產生時間差的問題。
以下連結為Juniper官方在SSG ScreenOS方面關於VPN設定的相關網頁：
關於VPN整體概念方面：
關於VPN設定方面：
關於VPN問題排除方面：
VPNis UP, but not passing traffic
以下連結為Juniper官方在SRX JunOS方面關於VPN設定的相關網頁：
Example: Configuring Hub-and-Spoke VPN between Junos and SSGdevices (CLI instructions)
Example: Configuring a Hub-and-Spoke VPN (CLI instructions)
而點到點的vpn設置一般分為二種情況：
一、兩端都有固定的IP位址(通常我們所討論的就是這種)。
二、一端是固定的IP位址，另一端則為動態的IP位址(這種就是所謂的Dynamic
VPN)。
下面為Route-Based
VPN Site B設定示範(根據vpn-b_router_cfg設定檔)：
##以下為環境相關介面設定，就不示範了
set interface "ethernet0/0" zone
"Untrust"
set interface ethernet0/0 ip 172.16.200.2/24 ##WAN介面，上網用
set interface ethernet0/0 route
set interface "bgroup0" zone "Trust"
set interface bgroup0 ip 192.168.2.1/24 ##LAN介面，您會連接的區網
set interface bgroup0 nat
set interface bgroup0 dhcp server auto ##設定LAN介面bgroup0為DHCP Server
set interface bgroup0 dhcp server option dns1 168.95.1.1 ##設定dns選項，沒設定client端會無法上網取得網址
set interface bgroup0 dhcp server option dns2 168.95.192.1
set interface bgroup0 dhcp server option gateway 192.168.2.1 ##設定預設閘道，沒設定client端會完全無法上網
set interface bgroup0 dhcp server option netmask 255.255.255.0
set interface bgroup0 dhcp server ip 192.168.2.11 to
192.168.2.111 ##設定派發位址池
我們在這裡的做法是將VPN通道tunnel.1加入untrust zone(區域)，設定較為簡單些，但是由於untrust區域還有wan介面存在，並且為不信任區域，會增加管理上以及安全上的負擔，所以另外建立一個vpn
zone來提供給vpn通道使用是易於管理、且較為安全的方式，故個人強烈建議大家必須另外建立一個vpn zone來提供給vpn通道使用。
其實我們在做vpn測試時還有一種取巧的方法，那就是將tunnel.1通道加入trust zone(標準的做法是單獨創建一個安全區然後將tunnel.1通道加入，例如vpn zone，後段會說明)，而這麼做又有甚麼好處呢?
那就是可以省略測試中[設定地址池和地址群組]以及[設定策略-開放內網與遠端vpn能互通]兩個步驟(後段會說明)，也就是在複雜環境測試時我們可以忽略策略(policy)方面的因素，而能專注在其他部分，當測試成功後，我們再將其套用在標準做法上，但這是非常不安全的做法，除了測試用途之外，請勿這麼做!
##第一步，建立vpn通道
CLI命令列設定如下：
set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip unnumbered interface ethernet0/0
其內容包含將通道加入Untrust zone，設定通道為unnumbered(不需要ip位址)，以及通道綁定之界面。
不同的介面有不同的用途，VPN通道在SSG與NETSCREEN系列的ScreenOS使用tunnel介面，而在SRX或是J系列的JUNOS則使用st0介面，第一個VPN通道為tunnel.1，第二個VPN通道為tunnel.2，以此類推，當然，您也可以直接將VPN通道設定成tunnel.168等等，而st0介面也相同。
一般一對一的vpn通道可以不需要指定ip位址，所以我們可以設定成unnumbered；但是若使用一對多的vpn通道，例如NHTB VPN的設定，我們就必須要幫通道設定ip位址了，這樣我們才能將網路流量明確的送達目的地。
其WebUI設定方式如下：
Network >
Interfaces(List) è 右上角下拉式選單選擇Tunnel
IF，然後點擊”New”。
下圖為點擊”New
”之後跳出的畫面(截取部分)，您只要根據指示，依照順序去設定即可。
##第二步，建立ike
gateway
CLI命令列設定如下：
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen"
proposal "pre-g2-3des-sha"
其內容包含設定閘道名稱，遠端閘道IP，主要模式或挑釁式模式，本地連外界面，Preshare Key與Phase 1提案proposal。
在這裡我麼要設定遠端閘道IP，好讓設備知道要跟誰建立vpn通道；Preshare Key在這裡我們使用"netscreen"方便測試使用，我們可以改得更複雜些，以提高安全性，最重要的是：Preshare
Key與Phase 1 proposal的設定是要跟對端設備的設定完全相同的。
關於主要模式或挑釁式模式：一般我們設定vpn都是選擇主要模式。當撥接
VPN 使用者使用預先定義的金鑰交涉「自動金鑰 IKE」通道時，必需使用挑釁式模式，由於參與者的身份是在純文字中交換的，所以挑釁式模式不提供身份保護。
其WebUI設定方式如下：
VPNs > AutoKey
Advanced > Gateway è New
下圖為點擊”New
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”Advanced
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”Return
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
##第三步，建立vpn
CLI命令列設定如下：
set vpn "site_b_a" gateway "site_a_GW"
no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set vpn "site_b_a" id 1 bind interface tunnel.1
set vpn "site_b_a" proxy-id local-ip 192.168.2.0/24
remote-ip 192.168.1.0/24 "ANY"
其內容包含建立vpn，指定Phase2 proposal，指定vpn綁定之通道界面，以及設定proxy-id。
每個vpn都必須綁定一個通道(tunnel)。
Phase2 proposal的設定必須跟對端設備的設定相同，而關於proposal的內容後面會說明。
proxy
ID 是一個三部份組合，由本機 IP位址、遠端 IP 位址和服務組成。兩個對等方的
proxy ID 必需配對，兩個對等方的 proxy ID 中指定的服務也必需相同，並且本機 IP 位址必需與遠端vpn設備指定的遠端IP位址相同。
ScreenOS也支援multi-proxy功能，若對端設備下含三個子網段，而您需要跟那三個子網段相互溝通，則您不必另外多建立兩個vpn通道，只需要利用現有通道即可，其CLI命令列設定如下：
set vpn "site_b_a" proxy-id local-ip 192.168.2.0/24
remote-ip 192.168.1.0/24 "ANY"
set vpn "site_b_a" proxy-id local-ip 192.168.2.0/24
remote-ip 192.168.3.0/24 "ANY"
set vpn "site_b_a" proxy-id local-ip 192.168.2.0/24
remote-ip 192.168.5.0/24 "ANY"
Multi-proxy與NHTB的差異在於：Multi-proxy是兩台建立VPN連線的設備其下各有數個子網段要透過一個VPN通道來互通，而NHTB則是一台網路設備僅使用一個VPN通道要來跟數台網路設備彼此建立起VPN連線。
NHTB設定請參考下列連結：
而又有哪些流量可以通過VPN通道呢?
在route-based VPN之中網路流量除了受到策略(POLICY)的控制之外，您還必須在靜態路由表中指定流量傳輸路徑，以及在VPN兩端VPN PROXY之中分別表列出近端與遠端要相互溝通端網段資料，三者缺一不可。也就是說當您的vpn通道建立起來後(ike phase1、phase2協議成功)，而您卻無法跟vpn遠端網段溝通，那您就必須檢查上述三者的設定是否正確。這也就說明了到底有哪些流量能夠使用vpn通道了。
其WebUI設定方式如下：
VPNs > AutoKey IKE
è
NEW
下圖為點擊”New
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”Advanced
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”Return
” 之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”OK ”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”Proxy
ID ”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
Multi-proxy的設定，只要依照新增proxy的步驟，將其餘的項目加入即可。
Multi-proxy的設定，只要依照新增proxy的步驟，將其餘的項目加入即可。
##第四步，建立路由，讓要去192.168.1.0/24網段走tunnel.1。
CLI命令列設定如下：
set route 192.168.1.0/24 interface tunnel.1
在路由表中明確指明要去192.168.1.0/24網段必須走tunnel.1介面。
路由表(Routing
Table)：存放了許多網段資訊或是主機ip位址等資訊，這些資訊會告訴您您要去的主機要經由哪個介面，介面下一個節點的ip為何?而您能快速正確的找到目的主機，可以說是因為路由表設定正確的原因。若路由表設錯，則您就無法與其他電腦連線溝通了。而如果路由表中沒有我們要訪問的主機資訊，我們又該怎麼辦?通常我們可以這麼做：
set route 0.0.0.0/0 interface ethernet0/0
next-hop 172.16.200.253
其中0.0.0.0/0代表的是所有的ip，ethernet0/0則是wan介面(連外界面)，而這個命令代表的意思是：所有沒有在路由表中找到目的路由資訊的流量，通通送往wan介面ethernet0/0，並傳送到下一個躍點172.16.200.253。這就表示尋找目的主機路由資訊的工作轉交給下一台連接的網路設備了(172.16.200.253)。而若始終沒有找到，就會導致愈時而無法連線。
其WebUI設定方式如下：
Network > Routing > Routing Entries è New
下圖為點擊”New
”之後所顯示的畫面，您只要根據指示，依照順序去設定即可。
下圖為點擊”OK ”後跳出以下畫面，顯示了新的路由已生效。
##第五步，建立政策讓本地端網段與VPN遠端網段能彼此互通。
CLI命令列設定如下：
set address
"Trust" "Local-192.168.2.0/24" 192.168.2.1 255.255.255.0
set address
"Untrust" "Remote-192.168.1.0/24" 192.168.1.1 255.255.255.0
set policy id 4
from "Trust" to "Untrust" "Local-192.168.2.0/24"
"Remote-192.168.1.0/24" "ANY" permit
set policy id 4
exit
set policy id 5
from "Untrust" to "Trust" "Remote-192.168.1.0/24"
"Local-192.168.2.0/24" "ANY" permit
set policy id 5
exit
set flow tcp-mss 1350
因為default
policy預設為deny all，也就是沒有允許的通通禁止通行，所以我們要為vpn通道建立允許互通的策略policy。而建立地址簿則可讓策略設定簡潔、易懂、明瞭、容易維護。
policy id 4的命令說明：凡是本地端192.168.2.0/24網段要從trust區域到untrust區域去訪問vpn遠端192.168.1.0/24網段的網路流量，一律允許。
WebUI設定從缺。
至此SSG5 Site B VPN設定已經完成。
而有關TCP-MSS配置參數設定其說明如下所示。
TCP-MSS 配置參數
TCP-MSS 作為TCP 三方握手的一部分進行協商，限制TCP 片段的最大大小以更好地匹配網路中的MTU 限制。
對於VPN 資訊流，IPsec 封裝開銷與IP 和幀開銷可導致生成的ESP 資料包超出物理介面的MTU，從而導致分段。分段會造成頻寬浪費和增加設備資源開銷。
注意: 對於大多數MTU 為1500 或以上、基於乙太網的網路，建議使用1350 作為起點。可能需要嘗試不同的TCP-MSS 值來獲取最佳性能。例如，如果路徑中的任何設備具有較低的MUT，或者如果存在其他開銷（如PPP 或框架轉送），則可能需要更改相關值。
set flow tcp-mss 1350 (ssg5)
set security flow tcp-mss
ipsec-vpn mss 1350 (srx)
以下這條命令非必要，只是說明而已。SRX st0.0通道預設mtu 9192，而SSG5 tunnel.1通道預設mtu 1500，所以當兩者互相建立vpn通道成功時，您會發現SRX到SSG5是正常的，而SSG5到SRX則不通，原因是當對方的mtu小於您時，您能接受，但是當對方的mtu大於您時，您就無法接受了。所以當SRX設備與非JunOS設備建立vpn通道時，建議要加上這條命令，而若能清楚知道對端設備的mtu值則就更完美了。
set interface tunnel.1 mtu 1500
ssg5-serial-> set interface
tunnel.1 mtu ?
<number> mtu
size, <1280-1500>
ssg5-serial->
set
interfaces st0 unit 0 family inet mtu 1500 (SRX的設定命令)
官方網站相關連結：
[ScreenOS]OSPF adjacencies fail when going through a route-based VPN between SRX and SSG
[Junos]OSPF will not come up because of MTU mismatch
[Junos]OSPF will not come up because of MTU mismatch
SSG5 Site B VPN設定列示如下：
set interface "ethernet0/0" zone
"Untrust"
set interface ethernet0/0 ip 172.16.200.2/24 ##WAN介面
set interface ethernet0/0 route
set interface "bgroup0" zone "Trust"
set interface bgroup0 ip 192.168.2.1/24 ##LAN介面
set interface bgroup0 nat
set interface bgroup0 dhcp server auto ##設定LAN介面bgroup0為DHCP Server
set interface bgroup0 dhcp server option dns1 168.95.1.1 ##設定dns選項，沒設定client端會無法上網取得網址
set interface bgroup0 dhcp server option dns2 168.95.192.1
set interface bgroup0 dhcp server option gateway 192.168.2.1 ##設定預設閘道，沒設定client端會完全無法上網
set interface bgroup0 dhcp server option netmask
255.255.255.0
set interface bgroup0 dhcp server ip 192.168.2.11 to
192.168.2.111 ##設定派發位址池
set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip unnumbered interface ethernet0/0
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen"
proposal "pre-g2-3des-sha"
set vpn "site_b_a" gateway "site_a_GW"
no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set vpn "site_b_a" monitor optimized rekey
set vpn "site_b_a" id 1 bind interface tunnel.1
set vpn "site_b_a" proxy-id local-ip 192.168.2.0/24
remote-ip 192.168.1.0/24 "ANY"
set route 192.168.1.0/24 interface tunnel.1
set address
"Trust" "Local-192.168.2.0/24" 192.168.2.1 255.255.255.0
set address
"Untrust" "Remote-192.168.1.0/24" 192.168.1.1 255.255.255.0
set policy id 4
from "Trust" to "Untrust" "Local-192.168.2.0/24"
"Remote-192.168.1.0/24" "ANY" permit
set policy id 4
exit
set policy id 5
from "Untrust" to "Trust" "Remote-192.168.1.0/24"
"Local-192.168.2.0/24" "ANY" permit
set policy id 5
exit
set flow tcp-mss 1350
而SSG5 Site A VPN設定列示如下：
CLI命令列設定如下：
set interface "ethernet0/0" zone
"Untrust"
set interface ethernet0/0 ip 172.16.200.1/24 ##WAN介面
set interface ethernet0/0 route
set interface "bgroup0" zone "Trust"
set interface bgroup0 ip 192.168.1.1/24 ##LAN介面
set interface bgroup0 nat
set interface bgroup0 dhcp server auto ##設定LAN介面bgroup0為DHCP Server
set interface bgroup0 dhcp server option dns1 168.95.1.1 ##設定dns選項，沒設定client端會無法上網取得網址
set interface bgroup0 dhcp server option dns2 168.95.192.1
set interface bgroup0 dhcp server option gateway 192.168.1.1 ##設定預設閘道，沒設定client端會完全無法上網
set interface bgroup0 dhcp server option netmask
255.255.255.0
set interface bgroup0 dhcp server ip 192.168.1.11 to
192.168.1.111 ##設定派發位址池
set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip unnumbered interface ethernet0/0
set ike gateway "site_b_GW" address 172.16.200.2
Main outgoing-interface "ethernet0/0" preshare "netscreen"
proposal "pre-g2-3des-sha"
set vpn "site_a_b" gateway "site_b_GW"
no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set vpn "site_a_b" monitor optimized rekey
set vpn "site_a_b" id 1 bind interface tunnel.1
set vpn "site_a_b" proxy-id local-ip 192.168.1.1/24
remote-ip 192.168.2.1/24 "ANY"
set route 192.168.1.0/24 interface tunnel.1
set address
"Trust" "Local-192.168.1.0/24" 192.168.1.1 255.255.255.0
set address
"Untrust" "Remote-192.168.2.0/24" 192.168.2.1 255.255.255.0
set policy id 4
from "Trust" to "Untrust"
"Local-192.168.1.0/24" "Remote-192.168.2.0/24"
"ANY" permit
set policy id 4
exit
set policy id 5
from "Untrust" to "Trust"
"Remote-192.168.2.0/24" "Local-192.168.1.0/24"
"ANY" permit
set policy id 5
exit
set flow tcp-mss 1350
其WebUI設定則從缺。
至此SSG5 Site A VPN設定也已經完成。
以下為原廠VPN相關連結：
[ScreenOS]How do I create a Policy Based LAN to LAN VPN using Preshared Keys (ScreenOS6.0 and later)
前述的做法是將VPN通道加入untrust zone(區域)，設定較為簡單些，但是由於untrust區域還有wan介面存在，並且為不信任區域，會增加管理上以及安全上的負擔，所以另外建立一個vpn zone來提供給vpn通道使用是易於管理、且較為安全的方式，故個人強烈建議大家必須另外建立一個vpn zone來提供給vpn通道使用。
以下為其較為完整的設定方式，請大家參考。
SSG5 Site A VPN設定(VPN ZONE)列示如下：
##設定VPN zone，將tunnel.1綁定在VPN zone，並指定介面IP
set zone id 100 "VPN"
set interface "tunnel.1"
zone "VPN"
set interface tunnel.1 ip
10.11.11.11/24
##設定Untrust zone，將ethernet0/0綁定在VPN zone，並指定介面IP
set zone "Untrust" vrouter
"trust-vr"
set interface "ethernet0/0"
zone "Untrust"
set interface ethernet0/0 ip
172.16.200.11/24
set interface ethernet0/0 route
##設定trust zone，將bgroup0綁定在VPN zone，並指定介面IP，以及bgroup0綁定的端口
set zone "Trust" vrouter
"trust-vr"
set interface "bgroup0" zone
"Trust"
set interface bgroup0 port ethernet0/2
set interface bgroup0 port ethernet0/3
set interface bgroup0 port ethernet0/4
set interface bgroup0 port ethernet0/5
set interface bgroup0 port ethernet0/6
set interface bgroup0 ip
192.168.1.1/24
set interface bgroup0 nat
##設定dhcp server以及其參數
set interface bgroup0 dhcp server
service
set interface bgroup0 dhcp server auto ##設定LAN介面bgroup0為DHCP Server
set interface bgroup0 dhcp server option dns1 168.95.1.1 ##設定dns選項，沒設定client端會無法上網取得網址
set interface bgroup0 dhcp server option dns2 168.95.192.1
set interface bgroup0 dhcp server option gateway 192.168.1.1 ##設定預設閘道，沒設定client端會完全無法上網
set interface bgroup0 dhcp server option netmask
255.255.255.0
set interface bgroup0 dhcp server ip 192.168.1.11 to
192.168.1.111 ##設定派發位址池
##設定VPN以及其參數
set ike gateway
"Site_B_Gateway" address 172.16.200.12 Main outgoing-interface
"ethernet0/0" preshare "netscreen" sec-level standard
set vpn "To-Site_B-VPN"
gateway "Site_B_Gateway" replay tunnel idletime 0 sec-level standard
set vpn "To-Site_B-VPN"
monitor optimized rekey
set vpn "To-Site_B-VPN" id 1
bind interface tunnel.1
set vpn "To-Site_B-VPN"
proxy-id local-ip 192.168.1.0/24 remote-ip 192.168.2.0/24 "ANY"
##設定讓兩端VPN相互溝通之策略policy
set address "Trust"
"local-net" 192.168.1.0 255.255.255.0
set address "VPN"
"remote-net" 192.168.2.0 255.255.255.0
set policy id 2 from "Trust"
to "VPN" "local-net"
"remote-net" "ANY" permit
set policy id 2
exit
set policy id 3 from "VPN"
to "Trust" "remote-net"
"local-net" "ANY" permit
set policy id 3
exit
##設定內網可以任意訪問外網之策略
set policy id 1 from "Trust"
to "Untrust" "Any"
"Any" "ANY" permit
set policy id 1
exit
##設定預設路由以及vpn路由資訊
set route 192.168.2.0/24 interface
tunnel.1 gateway 10.11.11.12
set route 0.0.0.0/0
interface ethernet0/0 gateway 172.16.200.253
##設定tcp-mss
set flow tcp-mss 1350
SSG5 Site B VPN設定(VPN ZONE)列示如下：
set zone id 100 "VPN"
set interface "tunnel.1"
zone "VPN"
set interface tunnel.1 ip
10.11.11.12/24
set zone "Untrust" vrouter
"trust-vr"
set interface "ethernet0/0"
zone "Untrust"
set interface ethernet0/0 ip
172.16.200.12/24
set interface ethernet0/0 route
set zone "Trust" vrouter
"trust-vr"
set interface "bgroup0" zone
"Trust"
set interface bgroup0 port ethernet0/2
set interface bgroup0 port ethernet0/3
set interface bgroup0 port ethernet0/4
set interface bgroup0 port ethernet0/5
set interface bgroup0 port ethernet0/6
set interface bgroup0 ip
192.168.2.1/24
set interface bgroup0 nat
set interface bgroup0 dhcp server
service
set interface bgroup0 dhcp server auto
set interface bgroup0 dhcp server
option dns1 168.95.1.1
set interface bgroup0 dhcp server
option dns2 168.95.192.1
set interface bgroup0 dhcp server
option gateway 192.168.2.1
set interface bgroup0 dhcp server
option netmask 255.255.255.0
set interface bgroup0 dhcp server ip
192.168.2.11 to 192.168.2.111
set flow tcp-mss 1350
set address "Trust"
"local-net" 192.168.2.0 255.255.255.0
set address "VPN"
"remote-net" 192.168.1.0 255.255.255.0
set ike gateway
"Site_A_Gateway" address 172.16.200.11 Main outgoing-interface
"ethernet0/0" preshare "netscreen" sec-level standard
set vpn "To-Site_A-VPN"
gateway "Site_A_Gateway" replay tunnel idletime 0 sec-level standard
set vpn "To-Site_A-VPN"
monitor optimized rekey
set vpn "To-Site_A-VPN" id 1
bind interface tunnel.1
set vpn "To-Site_A-VPN"
proxy-id local-ip 192.168.2.0/24 remote-ip 192.168.1.0/24 "ANY"
set policy id 1 from "Trust"
to "Untrust" "Any"
"Any" "ANY" permit
set policy id 1
exit
set policy id 2 from "Trust"
to "VPN" "local-net"
"remote-net" "ANY" permit
set policy id 2
exit
set policy id 3 from "VPN"
to "Trust"
"remote-net" "local-net" "ANY" permit
set policy id 3
exit
set route 192.168.2.0/24 interface
tunnel.1 gateway 10.11.11.12
set route 0.0.0.0/0
interface ethernet0/0 gateway 172.16.200.253
其實我們在做vpn測試時還有一種取巧的方法，那就是將tunnel.1通道加入trust zone(標準的做法是單獨創建一個安全區然後將tunnel.1通道加入，例如vpn zone)，而這麼做又有甚麼好處呢?
那就是可以省略下面測試中[設定地址池和地址群組]以及[設定策略-開放內網與遠端vpn能互通]兩個步驟，也就是在複雜環境測試時我們可以忽略策略(policy)方面的因素，而能專注在其他部分，當測試成功後，我們再將其套用在標準做法上，但這是非常不安全的做法，除了測試用途之外，請勿這麼做!
##設定地址池和地址群組
set address "Trust"
"Local-192_168_100_0-24" 192.168.100.0 255.255.255.0
set address "Trust"
"Local-192_168_2_0-24" 192.168.2.0 255.255.255.0
set group address "Trust"
"Local-Lans"
set group address "Trust" "Local-Lans"
add "Local-192_168_100_0-24"
set group address "Trust"
"Local-Lans" add "Local-192_168_2_0-24"
set address "VPN"
"Remote-192_168_1_0-24" 192.168.1.0 255.255.255.0
set address "VPN"
"Remote-172_16_168_0-24" 172.16.168.0 255.255.255.0
set group address "VPN" "Remote-Lans"
set group address "VPN" "Remote-Lans"
add "Remote-192_168_1_0-24"
set group address "VPN" "Remote-Lans"
add "Remote-172_16_168_0-24"
##設定策略-開放內網與遠端vpn能互通
set policy id 2 from "Trust" to
"VPN" "Local-Lans"
"Remote-Lans" "ANY" permit
set policy id 2
exit
set policy id 3 from "VPN" to
"Trust"
"Remote-Lans" "Local-Lans" "ANY" permit
set policy id 3
exit
下面繼續做點補充說明：
Juniper
Networks 安全性裝置最多支援四個「階段 1」交涉的提議(Proposal)，如果組態多個 ( 最多四個) 「階段 1」交涉提議(Proposals)，請在所有的提議中使用相同的Diffie-Hellman 群組。同樣的準則可套用到「階段 2」交涉的多個提議。
以下為CLI命令列示範：
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen" proposal
"pre-g2-3des-sha" "pre-g2-3des-md5"
"pre-g2-aes128-md5" "pre-g2-aes128-sha"
其WebUI設定方式如下：
您也可以選擇預先定義(Predefined)的提議(proposals)。
ScreenOS 提供的預先定義「階段 1」提議如下(在JUNOS上也相同)：
標準Standard: pre-g2-aes128-sha 和 pre-g2-3des-sha
相容Compatable: pre-g2-3des-sha、pre-g2-3des-md5、pre-g2-des-sha 和 pre-g2-des-md5
基本basic: pre-g1-des-sha 和 pre-g1-des-md5
ps：從上述內容我們可以看出，預先定義的提議"標準"加密演算法使用aes128-sha，而"相容"則不包含aes128-sha(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
ScreenOS 提供的預先定義「階段 2」提議如下(在JUNOS上也相同):
標準Standard: g2-esp-3des-sha 和 g2-esp-aes128-sha
相容Compatable: nopfs-esp-3des-sha、nopfs-esp-3des-md5、nopfs-esp-des-sha 和nopfs-esp-des-md5
基本basic: nopfs-esp-des-sha 和 nopfs-esp-des-md5
ps：從上述內容我們可以看出，預先定義的提議"標準"包含有DH Group，而"相容"則不包含DH Group(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
以下為階段一之預先定義CLI命令列設定示範：
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen" sec-level standard
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen" sec-level compatible
set ike gateway "site_a_GW" address 172.16.200.1
Main outgoing-interface "ethernet0/0" preshare "netscreen" sec-level basic
以下為階段二之CLI命令列設定示範：
set vpn "site_b_a" gateway "site_a_GW"
no-replay tunnel idletime 0 proposal
"g2-esp-3des-sha" "g2-esp-des-md5"
"g2-esp-des-sha" "g2-esp-aes128-sha"
set vpn "site_b_a" gateway "site_a_GW"
no-replay tunnel idletime 0 sec-level standard
而Phase 1 proposal
"pre-g2-3des-sha"與Phase 2 proposal
"g2-esp-aes128-sha"又各代表何義呢?
Phase 1 Proposal pre-g2-3des-sha涵義如下：
- Authentication method身份驗證方法: pre-shared-keys預先共享金鑰 (不是CA認證，但是還有dsa、rsa兩種CA認證方式可選)
- Diffie-Hellman group(DH Group): group2 (group1強度不夠則不推薦)
- Encryption algorithm驗證算法: 3des (共有des、3des、aes128三種可選)
- Authentication algorithm加密算法: sha (hmac-sha1-96，共有sha、md5兩種可選)
Phase 2 Proposal g2-esp-aes128-sha涵義如下：
- PFS(Perfect Forward Secrecy)完美轉送安全性: Diffie-Hellman group2 (g2就是使用PFS Group 2，nopfs就是不使用PFS)
- Protocol協定: esp封裝安全性負載
- Authentication algorithm驗證算法: sha (hmac-sha1-96，共有sha、md5兩種可選)
- Encryption algorithm加密算法: aes128 (aes-128-cbc，共有des、3des、aes128三種可選)
而JUNIPER SRX JUNOS的做法則又有所改善，如下圖：SRX Phase1 Proposal設定。
下圖為SRX Phase2 Proposal設定，但是少了PFS設定，要在另一頁籤中去設定。
下圖為SRX Phase2 Proposal PFS設定。
關於指令與設定精簡化方面，ScreenOS比JunOS要好，就以vpn的設定來說，以下為兩者間的比較:
Juniper SSG5設備的一行命令：
set ike gateway "site_b_GW" address 172.16.200.2
Main outgoing-interface "ethernet0/0" preshare "netscreen"
proposal "pre-g2-3des-sha"
而Juniper SRX100設備卻要這麼多行：
set security ike
proposal srx-ike-proposal authentication-method pre-shared-keys
set security ike
proposal srx-ike-proposal dh-group group2
set security ike
proposal srx-ike-proposal authentication-algorithm sha1
set security ike
proposal srx-ike-proposal encryption-algorithm 3des-cbc
set security ike policy
ike_pol_srx-to-srx mode main
set security ike policy
ike_pol_srx-to-srx proposals srx-ike-proposal
set security ike policy
ike_pol_srx-to-srx pre-shared-key ascii-text "netscreen"
set security ike gateway
Site1_GW ike-policy ike_pol_srx-to-srx
set security ike gateway
Site1_GW address 172.16.200.2
set security ike gateway
Site1_GW no-nat-traversal
set security ike gateway
Site1_GW external-interface fe-0/0/0.0
set security ike gateway
Site1_GW version v1-only
可怕吧! 這就好像寫程式用BASIC與C語言寫的差異一般。
以下敘述為原廠ScreenOS參考指南 中節錄下來的關於加密選項的內容：
站台到站台加密選項
組態基本的站台到站台
VPN 通道時，在圖19 中所示的加密選項中進行選擇。圖後會介紹每個選項的優點。
1.
金鑰方法:
自動金鑰(AutoKey IKE)或手動金鑰(Manual Key)?
自動金鑰 IKE
◎建議
◎提供自動金鑰更新和金鑰重新整理，因而增強了安全性
手動金鑰
◎用於除錯 IKE
◎消除建立通道時的 IKE 交涉延遲
2.
模式：挑釁式模式或主要模式?
挑釁式模式Aggressive
動態分配其中一個 IPSec 對等方的 IP 位址及使用預先共享金鑰時，需使用此模式
主要模式Main
◎建議
◎提供身份保護
◎撥接使用者擁有靜態 IP 位址時或如果認證用於驗證時，可以使用此模式
3.
驗證類型：預先共享金鑰或認證?
認證Certificates
◎建議
◎由於可以驗證具有認證授權機構 (CA-certificate authority) 的認證，因此提供比預先共享金鑰更高的安全級別。
預先共享的金鑰
由於不需要「公開金鑰基礎結構」(PKI)，因此使用更方便，設定更快速
4.
認證類型：RSA
或 DSA?
具體取決於從其獲得認證的 CA。兩種認證類型沒有優點。
5.
位元長度：512
或 768
或 1024
或 2048?
512
使處理開支最少
768
◎提供比 512 位元更高的安全等級
◎使處理開支比 1024 和 2048 位元的更少
1024
◎建議
◎提供比 512 和 768 位元更高的安全等級
◎使處理開支比 2048 位元的更少
2048
提供最高的安全等級
6.
IKE Diffie-Hellman 群組: 1 或 2 或 5?
Diffie-Hellman 群組 1
◎使處理開支比 Diffie-Hellman 群組 2 和 5 的更少
◎加快 Juniper Networks 安全性硬體中提供的處理速度
Diffie-Hellman Group 2
◎建議
◎使處理開支比 Diffie-Hellman 群組 5 的更少
◎提供比 Diffie-Hellman 群組 1 更高的安全等級
◎加快 Juniper Networks 安全性硬體中提供的處理速度
Diffie-Hellman 群組 5
提供最高的安全等級
7.
IKE 加密和 Auth
演算法:
AES 或 DES
或 3DES
及 MD5
或 SHA-1?
AES
◎建議
◎如果金鑰長度全部相等，則比
DES 和 3DES 的加密性更強
◎加快 Juniper Networks 安全性硬體中提供的處理速度
◎用於「聯邦資訊處理標準」(FIPS) 和「通用準則 EAL4」標準的經核准加密演
算法
DES
◎使處理開支比 3DES 和 AES 的更少
◎在遠端對等方不支援
AES 時非常有用
3DES
◎提供比 DES 更高的加密安全等級
◎加快 Juniper Networks 安全性硬體中提供的處理速度
MD5
使處理開支比 SHA-1 的更少
SHA-1
◎建議
◎提供比 MD5 更高的加密安全等級
◎FIPS 接受的唯一驗證演算法
8.
本機 IKE
ID：IP
位址 (
預設)
或 U-FQDN
或 FQDN
或 ASN1-DN?
IP Address
◎建議
◎本機安全性裝置具有靜態
IP 位址時才能使用
◎使用預先共享金鑰驗證時的預設
IKE ID
◎如果 IP 位址出現在 SubjectAltName 欄位中，則可與認證配合使用
U-FQDN
使用者完全合格的網域名稱 (U-FQDN - 電子郵件位址): 如果 U-FQDN 出現在SubjectAltName 欄位中，則可與預先共享金鑰或認證配合使用FQDN
◎完全合格的網域名稱
(FQDN): 如果 FQDN 出現在 SubjectAltName 欄位中，則可與預先共享金鑰或認證配合使用
◎對於具有動態 IP 位址的 VPN 閘道很有用
◎使用 RSA 或 DSA 認證驗證時的預設 IKE ID
ASN1-DN
◎只能與認證配合使用
◎在 CA 不支援其發佈的認證中的 SubjectAltName 欄位時很有用
9.
遠端 IKE
ID：IP
位址 (
預設)
或 U-FQDN
或 FQDN
或 ASN1-DN?
IP Address
◎建議
◎使用預先共享金鑰驗證並且對等方是安全性裝置時，不需要輸入靜態
IP 位址處對等方的遠端 IKE ID
◎可用於具有靜態 IP 位址的裝置
◎如果 IP 位址出現在 SubjectAltName 欄位中，則可與預先共享金鑰或認證配合
使用
U-FQDN
使用者完全合格的網域名稱 (U-FQDN - 電子郵件位址): 如果 U-FQDN 出現在SubjectAltName 欄位中，則可與預先共享金鑰或認證配合使用
FQDN
◎完全合格的網域名稱
(FQDN): 如果 FQDN 出現在 SubjectAltName 欄位中，則可與預先共享金鑰或認證配合使用
◎對於具有動態 IP 位址的 VPN 閘道很有用
◎使用認證驗證並且對等方是安全性裝置時，不需要輸入遠端
IKE ID
ASN1-DN
◎只能與認證配合使用
◎在 CA 不支援其發佈的認證中的 SubjectAltName 欄位時很有用
10.
反重播檢查(Anti-Replay Checking)：否或是?
是
◎建議
◎允許收件人檢查封包標頭中的序號，以防止用心不良者重新傳送截取的
IPSec封包時導致的「服務中斷」(DoS) 攻擊
否
停用此項可能會解決與協力廠商對等方的相容性問題
11.
完美轉送安全性：否或是?
是
◎建議
◎完美轉送安全性 (PFS-Perfect Forward Secrecy): 由於對等方執行第二個
Diffie-Hellman 交換生成用於IPSec 加密/ 解密的金鑰，因此提供增強的安全性
否
◎提供更快的通道設定
◎使「階段 2」IPSec 交涉期間處理開支更少
12.
IPSec Diffie-Hellman 群組: 1 或 2 或 5?
Diffie-Hellman 群組 1
◎使處理開支比 Diffie-Hellman 群組 2 和 5 的更少
◎加快 Juniper Networks 安全性硬體中提供的處理速度
Diffie-Hellman Group 2
◎建議
◎使處理開支比 Diffie-Hellman 群組 5 的更少
◎提供比 Diffie-Hellman 群組 1 更高的安全等級
◎加快 Juniper Networks 安全性硬體中提供的處理速度
Diffie-Hellman 群組 5
提供最高的安全等級
13.
IPSec 通訊協定:
ESP 或 AH?
ESP (Encapsulating
Security Payload)
◎建議
◎封裝安全性負載 (ESP): 透過加密和封裝原始 IP 封包可提供機密性，同時透過驗證提供完整性
◎可提供單獨加密或單獨驗證
AH (AH-Authentication Header)
驗證標頭 (AH): 提供整個 IP 封包的驗證，包括 IPSec 標頭和外部 IP 標頭
14.
模式：通道模式或傳輸模式?
通道模式(Tunnel)
◎建議
◎由於隱藏了初始 IP 標頭，因此增加了私密性
傳輸模式(Transport)
對於 IPSec 上的 L2TP 通道支援，此模式是必需的
15.
ESP 選項:
加密 或 加密/Auth
或 Auth?
加密(Encrypt)
◎提供比使用 加密/驗證 更快的效能並使處理開支更少
◎用於要求機密性但不要求驗證(authentication)的情況
Encrypt /Auth (加密/驗證)
◎建議
◎用於需要機密性和驗證的情況
Auth (驗證)
用於需要驗證但不要求機密性的情況。也許資訊不是保密時，但確定此資訊確實來自聲稱傳送它的人，以及在傳輸過程中沒有任何人篡改內容是很重要的。
16.
加密演算法：AES
或 DES
或 3DES?
AES
◎建議
◎如果金鑰長度全部相等，則比
DES 和 3DES 的加密性更強
◎加快 Juniper Networks 安全性硬體中提供的處理速度
◎用於 (FIPS) 和「通用準則 EAL4」標準的核准加密演算法
DES
◎使處理開支比 3DES 和 AES 的更少
◎在遠端對等方不支援
AES 時非常有用
3DES
◎提供比 DES 更高的加密安全等級
◎加快 Juniper Networks 安全性硬體中提供的處理速度
17.
Auth 演算法：MD5
或 SHA-1?
MD5
使處理開支比 SHA-1 的更少
SHA-1
◎建議
◎提供比 MD5 更高的加密安全等級
使用上述清單中建議的選項，具有靜態 IP 位址的兩台安全性裝置間的通用站台到站台 VPN 組態將由以下元件組成:
以下為Route-Based VPN連線時所產生的
Event Log 範例 ssg5 to ssg5
訊息請從一段的下方(最早發生)往上方(後來發生)看
=============================================================================
System Event Log (Current system time: Fri,
25 Aug 2017 00:08:26)
=============================================================================
SITE A 172.16.200.14 VPN正常連線
2017-08-26 01:02:48 info IKE 172.16.200.12
Phase 2 msg ID 1a73f5da: Completed negotiations with SPI
d092e046, tunnel ID 1, and lifetime 3600 seconds/0 KB.
2017-08-26 01:02:48 info IKE 172.16.200.12
phase 2:The symmetric crypto key has been generated successfully.
2017-08-26 01:02:48 info IKE 172.16.200.12:
Received a notification message for DOI 1 40001 NOTIFY_NS_NHTB_INFORM.
2017-08-26 01:02:48 info IKE 172.16.200.12
Phase 2: Initiated negotiations.
2017-08-26 01:02:48 info IKE 172.16.200.12
Phase 1: Completed Main mode negotiations with a 28800-second lifetime.
2017-08-26 01:02:48 info IKE 172.16.200.12
phase 1:The symmetric crypto key has been generated successfully.
2017-08-26 01:02:48 info IKE172.16.200.14
172.16.200.12 Phase 1: Initiated negotiations in main mode.
=============================================================================
SITE B 172.16.200.12 VPN正常連線
2017-08-26 01:02:48 info IKE 172.16.200.14
Phase 2 msg ID 1a73f5da: Completed negotiations with SPI 96ad6a0e, tunnel ID 1, and lifetime 3600
seconds/0 KB.
2017-08-26 01:02:48 info IKE 172.16.200.14
phase 2:The symmetric crypto key has been generated successfully.
2017-08-26 01:02:48 info IKE 172.16.200.14:
Received a notification message for DOI 1 40001 NOTIFY_NS_NHTB_INFORM.
2017-08-26 01:02:48 info IKE 172.16.200.14
Phase 2 msg ID 1a73f5da: Responded to the peer's first
message.
2017-08-26 01:02:48 info IKE 172.16.200.14
Phase 1: Completed Main mode negotiations with a 28800-second lifetime.
2017-08-26 01:02:48 info IKE 172.16.200.14
phase 1:The symmetric crypto key has been generated successfully.
2017-08-26 01:02:48 info IKE 172.16.200.14:
Phase 1 SA (my cookie:02a4bbf8)
was removed due to a simultaneous rekey.
2017-08-26 01:02:48 info IKE 172.16.200.14
Phase 1: Responder starts MAIN mode negotiations.
===========================================================================
End of System Event Log
=============================================================================
以下為Policy-Based VPN連線 Event Log 範例 ssg5 to ssg5
過程之中會故意設定錯誤或是中斷連線，主要是用來觀察與測試Event
Log所回應的訊息。
訊息請從一段的下方(最早發生)往上方(後來發生)看。
=============================================================================
System Event Log (Current system time: Fri,
25 Aug 2017 00:08:26)
=============================================================================
5.SITE A VPN正常連線
2017-08-25 21:27:52 info IKE 172.16.200.13
Phase 2 msg ID 0a9e6625:
Completed negotiations with SPI 62560e48, tunnel ID 2, and lifetime 3600
seconds/0 KB.
2017-08-25 21:27:52 info IKE 172.16.200.13
phase 2:The symmetric crypto key has been generated successfully.
2017-08-25 21:27:52 info IKE 172.16.200.13
Phase 2 msg ID 0a9e6625:
Responded to the peer's first message.
2017-08-25 21:27:52 info IKE 172.16.200.13
Phase 1: Completed Main mode negotiations with a 28800-second lifetime.
2017-08-25 21:27:52 info IKE 172.16.200.13
phase 1:The symmetric crypto key has been generated successfully.
2017-08-25 21:27:52 info IKE 172.16.200.13
Phase 1: Responder starts MAIN mode negotiations.
4.此時SITE B IP已改為正確之IP
2017-08-25 21:27:43 info IKE 172.16.200.13
Phase 1: Retransmission limit has been reached.
2017-08-25 21:26:55 info IKE172.16.200.11
172.16.200.13 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:26:43 info IKE 172.16.200.13
Phase 1: Retransmission limit has been reached.
2017-08-25 21:25:55 info IKE172.16.200.11
172.16.200.13 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:25:43 info IKE 172.16.200.13
Phase 1: Retransmission limit has been reached.
2017-08-25 21:24:55 info IKE172.16.200.11
172.16.200.13 Phase 1: Initiated negotiations in main mode.
3.SIT B 連線IP尚未更改，所以仍不通
2017-08-25 21:20:03 info IKE 172.16.200.13
Phase 1: Retransmission limit has been reached.
2017-08-25 21:19:43 info IKE 192.168.188.8
Phase 1: Retransmission limit has been reached.
2017-08-25 21:19:14 info IKE172.16.200.11
172.16.200.13 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:19:11 info System
configuration saved by netscreen via web from host 172.16.200.10 to
172.16.200.11:80 by netscreen.
2017-08-25 21:19:11 notif VPN Site-a-VPN with
gateway Site-a-GW and P2 proposal g2-esp-aes128-sha has been modified by
netscreen via web from host 172.16.200.10 to 172.16.200.11:80.
2017-08-25 21:19:11 notif Gateway Site-a-GW
at 192.168.188.8 in main
mode with ID [default peer id] has been modified by netscreen via web from host
172.16.200.10 to 172.16.200.11:80.
2.更改正確之SITE B 連線 IP
2017-08-25 21:18:54 info IKE172.16.200.11
192.168.188.8 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:18:42 info IKE 192.168.188.8
Phase 1: Retransmission limit has been reached.
2017-08-25 21:17:54 info IKE172.16.200.11
192.168.188.8 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:17:42 info IKE 192.168.188.8
Phase 1: Retransmission limit has been reached.
2017-08-25 21:16:54 info IKE172.16.200.11
192.168.188.8 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:16:42 info IKE 192.168.188.8
Phase 1: Retransmission limit has been reached.
2017-08-25 21:15:54 info IKE172.16.200.11
192.168.188.8 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:15:42 info IKE 192.168.188.8
Phase 1: Retransmission limit has been reached.
2017-08-25 21:14:54 info IKE172.16.200.11
192.168.188.8 Phase 1: Initiated negotiations in main mode.
1.SITE A無法與SIT B 連線
=================================================================================================
4.SITE B VPN正常連線
2017-08-25 21:27:39 info IKE 192.168.188.11
Phase 1: Retransmission limit has been reached.
2017-08-25 21:27:20 info IKE 172.16.200.11
Phase 2 msg ID 0a9e6625:
Completed negotiations with SPI e5c90763,
tunnel ID 2, and lifetime 3600 seconds/0 KB.
2017-08-25 21:27:20 info IKE 172.16.200.11
phase 2:The symmetric crypto key has been generated successfully.
2017-08-25 21:27:20 info IKE 172.16.200.11
Phase 2: Initiated negotiations.
2017-08-25 21:27:20 info IKE 172.16.200.11
Phase 1: Completed Main mode negotiations with a 28800-second lifetime.
2017-08-25 21:27:20 info IKE 172.16.200.11
phase 1:The symmetric crypto key has been generated successfully.
2017-08-25 21:27:20 info IKE172.16.200.13
172.16.200.11 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:27:12 info System
configuration saved by netscreen via web from host 172.16.200.10 to
172.16.200.13:80 by netscreen.
2017-08-25 21:27:12 notif Session (id 8061
src-ip 172.16.200.13 dst-ip 172.16.200.11 dst port 0) route is valid.
2017-08-25 21:27:12 notif Session (id 8062
src-ip 172.16.200.13 dst-ip 172.16.200.11 dst port 0) route is valid.
2017-08-25 21:27:12 notif VPN Site-b-VPN with
gateway Site-b-GW and P2 proposal g2-esp-aes128-sha has been modified by
netscreen via web from host 172.16.200.10 to 172.16.200.13:80.
2017-08-25 21:27:12 notif Gateway Site-b-GW
at 192.168.188.11 in
main mode with ID [default peer id] has been modified by netscreen via web from
host 172.16.200.10 to 172.16.200.13:80.
3.更改正確之SITE A 連線 IP
2017-08-25 21:27:06 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies
68701de461310ba2 and 0000000000000000 because an initial Phase 1 packet arrived
from an unrecognized peer gateway.
2017-08-25 21:27:02 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies
68701de461310ba2 and 0000000000000000 because an initial Phase 1 packet arrived
from an unrecognized peer gateway.
2017-08-25 21:26:57 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies
68701de461310ba2 and 0000000000000000 because an initial Phase 1 packet arrived
from an unrecognized peer gateway.
2017-08-25 21:26:53 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies
68701de461310ba2 and 0000000000000000 because an initial Phase 1 packet arrived
from an unrecognized peer gateway.
2017-08-25 21:26:50 info IKE172.16.200.13
192.168.188.11 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:19:28 info IKE 192.168.188.11
Phase 1: Retransmission limit has been reached.
2017-08-25 21:19:25 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:21 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:17 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:13 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:09 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:05 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:19:01 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:18:57 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:18:53 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:18:49 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:18:45 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2017-08-25 21:18:41 info Rejected an IKE
packet on ethernet0/0 from 172.16.200.11:500 to 172.16.200.13:500 with cookies 47301c22c6b0c520 and 0000000000000000 because an initial Phase 1
packet arrived from an unrecognized peer gateway.
2.此時SITE A已更改正確之SITE B 連線 IP，但是SITE B的連線IP仍錯誤
2017-08-25 21:18:40 info IKE172.16.200.13
192.168.188.11 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:18:28 info IKE 192.168.188.11
Phase 1: Retransmission limit has been reached.
2017-08-25 21:17:40 info IKE172.16.200.13
192.168.188.11 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:17:28 info IKE 192.168.188.11
Phase 1: Retransmission limit has been reached.
2017-08-25 21:16:40 info IKE172.16.200.13
192.168.188.11 Phase 1: Initiated negotiations in main mode.
2017-08-25 21:16:28 info IKE 192.168.188.11
Phase 1: Retransmission limit has been reached.
2017-08-25 21:15:40 info IKE172.16.200.13
192.168.188.11 Phase 1: Initiated negotiations in main mode.
1.SITE B無法與SIT A 連線
=============================================================================
End of System Event Log
=============================================================================
