ZCNE Security Level 1 – IPSec VPN Module

level one IPSec VPN module in this module we will discuss the following topics basic concepts of VPN IPSec VPN to include authentication md5 and sha-1 des Triple DES and RSA AES diffie-hellman key exchange security protocols aah and ESP authentication and IPSec modes security associations or SAS and configuration examples and finally VPN h.a or VPN high availability basic concepts of VPN what is VPN VPN stands for virtual private network in the past when transmitting data in a secure way networks would need to have a costly site-to-site leased line between the sites a VPN gives users a secure way to access corporate network resources over the internet or other public or private networks without the expense of leased site to site lines a secure VPN is a combination of tunneling encryption authentication access control and auditing technologies and services used to transport traffic over the Internet or any insecure network that uses the tcp/ip protocol suite for communication there are many reasons for using a VPN first is security which includes the following authentication with authentication a VPN receiver can verify the source of the packets and guarantee the data integrity encryption with encryption a VPN guarantees the confidentiality of the original user data integrity because the packets are numbered sequentially with IPSec and encrypted and authenticated packet tampering is improbable and replay detection prevents malicious attacks the second reason is cost which includes reducing the number of access lines many companies pay monthly charges for two types of access lines either high-speed links or their primary internet access or frame relay ISDN primary rate interface or t1 lines to carry data a VPN may allow a company to carry data traffic over its internet access line thus reducing the need for some installed lines it also cuts long-distance phone charges long-distance phone charges are reduced with a VPN because the user typically dials a local call to an ISP rather than placing long-distance calls directly to the home office a remote site when dialing into the company's VPN benefits of a VPN tell a VPN tunnel has the following benefits we know that IP based networks have a weakness related to the structure of IP itself ip's original architects had no reason to provide any security features at the IP level and eyepiece flexibility allows for some creative use of the protocol that defeats traffic auditing access control and many other security measures IP based network data is therefore wide open to tampering and eavesdropping so with tunneling protocol packets of one type of network are put inside or encapsulated in the protocol packets of another network or transport across that network this ensures security of the data transmission IPSec VPN Internet Protocol security or IPSec is a standards-based VPN des offers flexible solutions for secure data communications across a public network in the traditional network layer IP packets have no inherent security it is relatively easy to forge the address of IP packets modify the contents of IP packets replay old packets and inspect the contents of IP packets in transit therefore there are no guarantees in IP Datagram transmission IPSec is a method of protecting the IP Datagram it is built around a number of standardized cryptographic techniques to provide confidentiality data integrity and authentication at the IP layer IP does not inherently provide any protection to your transferred data it does not even guarantee that the sender is verified IPSec tries to remedy this these services are considered distinct but IPSec supports them in a uniform manner benefits include confidentiality the IPSec sender can encrypt packets before transmitting them across the network integrity the IPSec receiver can validate packets sent by the IPSec sender to ensure that the data has not been altered during transmission authentication the IPSec receiver can verify the source of IPSec packets and guarantee the data integrity replay detection we use replay detection to ensure a transaction can only be carried out once unless we are authorized to repeat it an example it should not be possible for someone to record a transaction and then replay it verbatim in order to get an effect of multiple transactions being received by the peer consider also that the attacker must know the purpose of the traffic by means other than cracking the encryption and that the traffic will cause events favorable for him again a VPN provides secure communication between sites without the expense of lease site-to-site lines a secure VPN is a combination of tunneling encryption authentication access control and auditing it is used to transport traffic over the Internet or any insecure network that uses tcp/ip for communication before data is protected by an IPSec VPN i ke phase one and phase two negotiation must first be invoked after the phase one negotiation secure parameters including encryption and authentication algorithms and keys are generated these parameters are used to protect data which we call a secure tunnel phase two negotiation is then under the protection of this tunnel after phase two negotiations another set of secure parameters are generated these parameters are also used to construct another secure tunnel a VPN finally uses this second tunnel for data transmission data is encrypted or authenticated according to the secure parameters negotiated in Phase two UDP with protocol number 17 and port 500 are used for ika phase 1 and phase 2 negotiations asked the data transmission ESP protocol 50 or aah protocol 51 are used note that these are protocols like TCP or UDP not TCP or UDP ports authentication relies heavily on a hash function for the md5 hash function the input can be any length and any type but the output will always be a fixed length text file the output of md5 is 128 bits or 16 bytes digest for the authentication hash you can use either md5 or sha-1 md5 and sha-1 are thus 4 md5 the input has no limitation of length the output of md5 as stated earlier is a 128 bits or 16 bytes digest and md5 is faster at hashing than sha-1 sha-1 might be slower to hash but the output of sha-1 is a 160 bits or 20 bytes digest because it supports a larger digest it's stronger against brute-force attacks making sha-1 more secure similarly sha-256 and sha-512 are harder to compute but are even stronger against brute-force attacks due to their increasing output bits obviously sha-512 is going to be the strongest but also has the most CPU intensive usage as depicted on this figure encryption and decryption is a cyclic procedure at first the plaintext is input to the encryption algorithm and a ciphertext is generated as output then the ciphertext is input into the decryption algorithm and the input is generated as output there are two types of encryption algorithms symmetric and asymmetric if the encryption key and decryption key are the same we call this asymmetric encryption algorithm such as data encryption standard or des if the encryption key and decryption key are different it is an asymmetric encryption algorithm such as the Rivest Shamir Adelman standard or RSA this diagram shows the symmetric cryptography workflow using the same secret key to encrypt plaintext and decrypt ciphertext this diagram shows the asymmetric cryptography workflow using different security keys to encrypt plaintext and decrypt the ciphertext Duffey Hellman key exchange is used to create something called a shared secret a shared secret is made when two networking devices create a key from pre-shared keys or certificates and then share part of it with the peer the first task is for each network device to create a key pair one mathematical expression is generated from it two keys are formed a private key and a public key each network device will send its public key to its peer the private key is never shared with any other device but it is linked mathematically to the public key in this way in combination with a pre-shared key or certificate each peer is able to complete the decryption key so that one peer can decrypt traffic from the other and vice versa the zywall USG supports diffie-hellman key groups for encryption keys dh1 uses a 768 bit random number dh2 uses a ten hundred twenty-four bit random number dh5 uses a 1536 bit random number the longer the key the more secure the encryption but also the longer it takes to encrypt and decrypt information there are two security protocols in IPSec ESP encapsulation security payload and 8h or authentication header an ESP packet is identified by the protocol field 50 of an IP header and a age packet is protocol 51 the above three figures show the original IP packets and IP packets after ESP and 8h respectively for ESP and aage packets and ESP a age header is inserted between the IP header and the upper data layer ESP can provide both encryption and authentication and it's possible to do ESP without either however it's invalid to have ESP without encryption and authentication because it provides no security when applying encryption the ESP header is not encrypted but the upper data layer and a portion of the ESP trailer are although a H can only provide authentication it doesn't only authenticate the age header and the upper data layer but also the IP header the aah header includes a next header payload length spi sequence number and authentication data the next header field indicates the type of data that is contained in the protected data field namely IP and IP or TCP the payload length field indicates the length of the header itself and a 32-bit word – to the reserved field is not used and must be set to 0 SPI along with the destination IP address and security protocol is used to identify the security associations the sequence number is an incremental e increasing counter that is identical to that used in ESP the authentication data field is used to hold the result of the data integrity check because aah authenticates the whole IP header the IP header can't be altered during transmission in other words aah is not a NAT friendly protocol the ESP header includes SPI and sequence number SPI or the security parameter index along with the destination IP address and security protocol is used to identify the SI it is authenticated but not encrypted because it's used to identify the state encryption algorithm and key used to decrypt the packet if the SPI was encrypted would have a serious chicken-and-egg problem sequence number provides anti replay service to ESP this value is a unique and incrementally increasing number inserted to the header by the sender the sequence number is also authenticated but not encrypted this is because we want to determine whether a packet is a duplicate before expending a resources to decrypt it IV or initial vector is required when applying some encryption algorithm such as des in CBC mode note that the IV is not encrypted along with the protected data padding is used to maintain boundaries certain modes of encryption algorithm require the input to the cipher to be a multiple of its block size padding accomplishes this the authentication data field is used to hold the result of the data integrity check ESP provides confidentiality by encryption algorithm such as des and Triple DES and data integrity and data source authentication through authentication algorithm like md5 or sha-1 snubber helps to protect against replay attacks to provide data integrity and data source authentication an authentication procedure must be conducted several steps are involved one would generate a mac or message authentication code the message and shared keys are input into a function called the H nak to the sender then sends the message attached with the Mac to the receiver 3 the receiver generates a new Mac Prime with the received message and shared keys as the sender did forth with the Mac and Mac Prime are equal the message is authenticated the IPSec protocol page and ESP can be used to protect either the entire IP payload or the upper layer protocols of an IP payload this distinction is handled by considering two different modes of IPSec transport mode and tunnel mode transport mode is mainly for an IPSec host to protect data generated locally while tunnel mode is for security gate ways to provide IPSec services for other machines lacking of IPSec capability however there is no restriction that the IPSec hosts and the security gateway must be separate machines both IPSec protocols aah and ESP can operate in either transport mode and tunnel mode as mentioned before aah like ESP has transport mode and tunnel mode transport mode is used to protect the upper layer protocols tunnel mode is used to protect the entire IP Datagram and a new IP header is added to that transport mode can only be used to protect packets where the communication endpoint is also the cryptographic endpoint the aah data format in tunnel mode is illustrated here the entire protected IP packet is encapsulated and the aah header and new IP header is added to that the outer IP Datagram contains the address of the IPSec endpoints the inner IP Datagram contains the original addressing of the communication telemundo protect packets where the communication endpoint is not the same with the cryptographic endpoint the ESP data format in transport mode is illustrated here transport mode can only be used to protect packets where the communication endpoint is also the cryptographic endpoint the ESP data format in tunnel mode is illustrated here the entire protected IP packet is encapsulated in the ESP header and a new header is added to that the outer IP Datagram contains the address of the IPSec endpoints the inner IP Datagram contains the original addressing of the communication total mode can be used to protect packets where the communication endpoint is not the same with the cryptographic endpoint security associations or essays form the basics of IPSec the SI is the contract between the two communication entities it specifies how to protect data such as what encryption algorithm the authentication algorithm keys and so forth are being used for securing the packets i ke or internet key exchange is based on a framework defined by the internet security association and key management protocols is a KMP two separate phases are involved in I ke and phase one peers negotiate an i ke si to establish an authenticated and secure channel between themselves in Phase two IPSec essays are established for the subsequent data transmission since the I ke a si is already authenticated it can be used to provide source authentication integrity and confidentiality to all messages in Phase two there are three modes for i ke phase one and phase two negotiation main mode or aggressive mode can be chosen for a phase one negotiation quick mode is always applied to phase two i ke negotiation packets no matter main mode or aggressive mode or mode are transmitted via UDP 500 data transmission between IPSec endpoints via ESP or a H protocols can only be done after IPSec essays have been successfully negotiated in the first step of phase 1 i ke negotiates the security parameters such as encryption algorithm hash algorithm diffie-hellman group authentication method and so forth according to the policy pre-configured in each side secondly diffie-hellman key exchange takes place to generate the shared secret upon completion of the diffie-hellman exchange the two peers have a shared secret which may be used to protect their communication but the secret is not authenticated therefore the final step is to authenticate the secret the pre shared key can be used to authenticate the secret i ke s a negotiation using main mode consists of three two-way exchanges between the SI initiator and the responder in the first exchange both sides agree on basic security parameters such as encryption and authentication algorithms in the second exchange both sides exchange public keys for diffie-hellman exchange and pass each other and nonce which is a random number for partners to sign and thus verify its identity in the third exchange both sides authenticate their identities to each other namely to authenticate the secret exchange in the second exchange the parties actually use the generated shared defi Hellman values in three permutations to generate derivations authentication key and encryption key the derivation key is used for generating additional keys in Phase two the authentication key and encryption key are to be used for the I ke s a an aggressive mode as much information as possible is passed in the first packets such as sa diffie-hellman public value a nonce for the other party to sign and an idea that the responder can use to check the initiators identity with a third party the responder then sends back everything needed to complete the exchange including an optional certification payload and digital signature finally the initiator confirms the exchange and also sends its certification and signature to the responder to verify its identity compared to Maine mode which requires six packets total between peers aggressive mode is faster than main mode because the initiator sends everything in the first transaction and only three packets total however the security level is less than that of Maine mode this is because the transaction packets are not encrypted in aggressive mode in Phase two to pierce negotiate general-purpose IPSec essays under the protection of the I ke s a negotiated in phase one the parameter of the IPSec si includes the following security protocol that is the protocol used to carry data encryption the encryption function typically des Triple DES or AES authentication which is the authentication function such as sha or md5 diffie-hellman group if PFS or perfect forward secrecy is not applied the keys used for IPSec essays are derived from the diffie-hellman secret exchange in phase one if PFS is applied an additional diffie-hellman exchange is performed to generate keys for IPSec essays finally there's the mode either transport mode war tunnel mode peers also need to establish a policy were in local and remote networks are to be protected by the VPN tunnel quick mode is a three packet exchange like aggressive mode since the identities of both initiator and responder have been verified in previous phase one it is needless to follow the three pair step as in main mode if PFS is not applied new keys are derived from the diffie-hellman secret exchange and they one if it is applied an additional tiffy Helmand exchange is performed to generate keys for IPSec assays the responder then sends back everything needed to complete the exchange including an optional certification payload and digital signature finally the initiator confirms the exchange and also sends its certification and signature to the responder to verify its identity an IPSec VPN tunnel is usually established into two phases each phase establishes a security Association asked previously discussed the first phase establishes an i ke si between the zywall USG and the remote IPSec router the second phase uses the i ke si to securely establish an IPSec si through which the sidewall USG and remote IPSec router can send data between computers on the local and remote networks gateway types include the following site to site which is a remote IP set router that uses a static IP address site-to-site with dynamic peer which is a remote IPSec router that uses a dynamic IP address and remote access which is the remote peer is an IPSec VPN client such as a computer or smartphone with an IPSec software client to configure an IPSec VPN connection you must follow the steps shown first here's the VPN gateway to specify the IPSec routers at either end of a VPN tunnel and the i ke sa settings you can also activate and deactivate each VPN gateway next here's the VPN connection to specify which VPN gateway a VPN connection policy uses and which devices can use the VPN tunnel and IPSec sa settings you can also activate and deactivate and connect or disconnect each VPN connection then after the VPN gateway and VPN connection are configured a direct route will be automatically created by the Sai while US v to route traffic based on the phase 2 settings if you need to further customize which networks can route through the VPN tunnel you will also need to configure the policy route to specify which source addresses can be used in the IPSec VPN scenario one shows the most common IPSec VPN application using IPSec VPN to connect to different sites if both of them have a static IP address it's called a site-to-site IPSec VPN in the figure above you can see the configuration information on both phase one and phase two when configuring your IPSec parameters you must consider proper parameters for my address Piron address and pretty shared key in phase one and local policy and remote policy and phase two these will be relative to the zywall USG you're configuring for example the my address for one Pierre will alternately be the Pierre gateway for the other Pierre to begin configuring an IPSec tunnel go to the configuration VPN IPSec VPN menu and click on the Gateway tab to make your way to the Gateway or phase one policy add or edit a new policy to see the menus shown here use the drop down menu to specify the interface that will be used to connect to the remote site and then enter the IP address of the remote site in the static address field making note of the interfaces IP address so you can use it on the others I bought US GDP NP R the pre shared key will be used to authenticate the data integrity therefore you must enter the same pre shared key on both devices in the configuration VPN IPSec VPN menu on the connection tab you can add or edit your connection or phase 2 policy to see the menu shown here you can choose the different VPN gateway types in this configuration page we will discuss these 3 gateway types in detail in the next section here we are configuring a site-to-site VPN therefore we just need to enable the site-to-site check box and then select the correct VPN gateway configured in the previous step from the drop-down menu in the policy section you must choose which addresses are allowed to cross the VPN tunnel to the remote peer you must also select to which remote addresses those local machines can communicate you can choose an existing address range or create a new address object the site-to-site with dynamic peer VPN is quite similar to the site-to-site VPN the only difference between them is that the site to site with dynamic VPN doesn't contain the IP address of the remote site and the VPN tunnel can only be established by the dynamic peer please note that for the dynamic IP address VPN tunnel after the tunnel is established the system will automatically generate routes for the corresponding VPN traffic therefore no policy route is needed for dynamic EPN the next scenario is remote access this is only for an IPSec VPN client such as a computer with an IPSec software on it or a smartphone with an IPSec client on it by default the policy route will be created by the system when the SI is created if you would like to do more management you'll have to enable use policy route to control IPSec VPN rules which will be discussed later if you enable this function however as discussed the auto destination address also needs to be enabled again we'll discuss this later policy routes are typically generated automatically after the device establishes a VPN connection this is called a direct route however you can use policy route to control dynamic IP SEC rules to allow the administrator to create corresponding policy routes manually this feature provides more flexibility for management of IPSec VPN tunnels when sending IPSec traffic across the VPN tunnel empty you can cause problems this is because IPSec adds additional overhead to the original packets if the packet size is greater than the maximum MTU allowed on the interface where the crypto map is applied and if the do not fragment bit is set then the samel USG will drop the packets therefore you can use the ignore don't fragment setting in the ipv4 header to tell the zywall to ignore this bit and therefore not have it drop IPSec packets by fragmenting them instead we will discuss this feature in detail more later in this presentation in zld 4.10 the feature use policy route to control IPSec VPN rule is disabled by default the system will still create direct routes as previously discussed for VPNs automatically but we can use policy reps to control IPSec traffic instead if we enable this feature why do we want to use policy routes to control the VPN rules for dynamic peers in the example above if you use the policy route created by the system this means that all traffic will be sent when the destination is 192 168 2.0 / 24 but you cannot control the bandwidth or restrict the access rights of some servers on the remote site using a policy route the administrator can now define which pcs can or cannot be reached if you would like to control the bandwidth for the remote IPSec VPN clients you mind enable be used the policy route to control IPSec VPN rules but in the policy route configuration page you must specify the destination address so what should be entered in this field you can't use any for the destination address because that would encapsulate all traffic from the sowell USG into the IPSec tunnel but at the same time you don't know what the exact IP address of the remote IPSec VPN client is either the auto destination address field is displayed only when you select a VPN tunnel in the type field and the remote pier has a dynamic IP address enable this feature to have the scible USG used the IP address of the peer that initiated an incoming dynamic IPSec tunnel as the destination address of the policy route Y fragment packets normally after the additional overhead on the packets is imposed by IPSec the packet length might be greater than the MTU allowed on the interface and the zywall us you will normally fragment these packets to send them out if the packet length is greater than the MTU allowed on the interface and that don't fragment or DF bit is used the zywall us you will not fragment the packets but instead drop them directly which obviously may cause problems in some applications instead the sigh while USG can be configured to ignore the DF bit and forth design while USG to fragment these packets to get around this MTU issue with IPSec you can toggle the ignore don't fragment setting in the ipv4 header feature in the configuration VPN IPSec VPN menu in the VPN connection tab meaning it's a global setting for all IPSec tunnels on the sidewall USG which makes sense given that you'll be probably using the same outgoing interface for most of your VPN tunnels shown here is a packet capture with the DF bit disabled in the ipv4 header you'll note that the bit is instead marked has not set meaning that this packet can be fragmented by the saw ball us sheath but only because the VPN client allows us to do this if we enable the ignore don't fragment feature the zywall USD will fragment all sent packets that are larger than the MTU even if they don't fragment did on the IP header is set to be on this means that even if the clients don't wish for packets to be fragmented the sowell USG may have fragmented them anyhow to prevent them from being dropped due to the LAN MTU limitation scenario six hug and spoke VPN or VPN concentrator a VPN concentrator routes all VPN traffic's across multiple remote sites without complex settings this reduces configuration overhead and prevents the possibility of configuration errors a VPN concentrator also provides centralized management since all traffic has to go through it before transmitting to the remote sites thus the administrator can set up different access control rules based on the source address remote address user and schedule to enhance VPN security network access records are stored in the centralized office for further analysis to use this feature go to the configuration VPN IPSec VPN concentrator menu VPN concentrator configuration is done by adding already configured VPN connection members the VPN concentrator will automatically route VPN traffic among the members therefore you don't have to manually configure the policy routes to route remote branch traffic to the VPN tunnels making this up extremely easy on the VPN connection configuration page you can also configure inbound outbound traffic NAT we'll discuss this now in the next few slides I'll bound s NAT is aimed to hide the real local network on the remote VPN site the application shown here is rare and suitable only for one-way traffic because the remote site can't find a way to send packets back until we set up an inbound de NAT rule to translate the dnat to the real local network addresses in this application however we have outbound s NAT at both ends this application is meant to solve the local subnet overlapping problem without modifying the original network structure for example the original site subnet is 192.168.1.1 other site has been merged into the VPN scope this additional site also uses 192.168.1.1 to modify the whole network deployment due to the extra configuration effort and possibly having to change addresses on servers and other static IP address equipment because IPSec relies upon routing from one subnet to another each side of the VPN tunnel must be a different subnet for routing to correctly occur in this case we have to use outbound s not at both ends and inbound Dina to overcome the overlapping internal subnet issue in this scenario inbound Dina works as as I well USG virtual server it can redirect the VPN traffic to the internal server the user needs to pay special attention to the configuration on the firewall rule and policy routes on the za while USG with the server to make sure packets can reach the specific server for example VPN DMZ traffic may be blocked by default requiring a security policy to allow this traffic to be forwarded in this final scenario the inbound s snap will modify the esnatt to a fake address and then the local user has no way to find the remote VPN local network segment this application is meant to protect a remote subnet but the VPN will become a one-way transmission such an example would be for a remote site sending logs and reports to a collector at the main office VPN high availability or VPN H a IPSec VPN failover is a mechanism for providing a backup VPN tunnel once the main tunnel is disconnected from firmware to point to 0 and above IPSec VPN fallback is supported on the side wall u.s.

G Series it also has a mechanism to renegotiate the main tunnel even when the backup VPN tunnel is still up it is better for enterprise to maintain 100% uptime without failure by providing a secondary VPN tunnel in this manner remote branch offices do not need to worry about an IPSec outage causing trouble in accessing internal resources from the headquarters additionally VPN tunnel usage can reduce the total enterprise running costs in tangible and intangible ways in this scenario the sowell USD branch has two Wan links one to is p1 and another to is p2 to ensure high availability of the VPN tunnel between the hqz while USG and the branch died while USG we need to configure VPN failover in the branch design wall USG when the primary VPN tunnel goes down because is p1 is down the branch is I while USQ will negotiate another VPN tunnel with land 2 to the HQ zywall USG since users expect the main VPN tunnel to return after the primary VPN gateway it becomes available again the IPSec VPN fallback procedure is needed once again after failover occurs the fallback mechanism and a branch Sahiwal us she will try to negotiate with when one of the branch sidewall USG to rebuild the tunnel once when one becomes available the main VPN tunnel will replace the backup tunnel the Gateway policy HQ will look like a typical site to dynamic client example because HQ in our example has only one one interface it's specified in D my address section because the branches I while USG is using Wan DHCP the peer gateway address is set to dynamic address HQs connection settings are also similar to our previous examples with the appropriate local and remote networks referenced into corresponding policies now the branch will leave the domain name ipv4 field set to 0.0.0.0 to not specify either one interface because HQ in our example has only one gateway address no other settings are required however if HQ did have a secondary redundant gateway like an additional LAN connection it could be specified in the secondary peer gateway address field we'll talk more about this later in this section like H Hughes connection settings the appropriate local and remote networks are referenced in the corresponding policies on the branches I wall us G since VPN is not aware which interface is active and which interface is passive we have twin able to see a lie on the branch site to keep the VPN always on the active interface when it's alive you can do this by using the commands shown here on the CLI through console telnet SSH or the Java console interface on the web GUI here you can see examples of the VPN monitor when the tunnel is active when the main connection is down and the secondary connection is up and when the main connection comes back up to resume its VPN role in this example the hqz while USG has to wank connections for V can't high-availability this being the case how do we go about configuring the branch office to use both of those interfaces the gateway connection for HQ remains unchanged from our previous example with one important exception the domain name ipv4 address for my address is left at IP address zero zero zero zero this enables HQ to accept incoming VPN requests on any one interface HQs VPN connection settings are unchanged from the previous example on the branch sidewall USG we have to peer gateway addresses a primary and secondary address you'll also note that fallback to primary gateway when possible is checked when this feature is enabled if the connection to the primary address goes down and the zywall USG changes to using the secondary connection the zywall USG will reconnect to the primary address when it becomes available again and stops using the secondary connection users will lose their VPN connection briefly when the zywall USG changes to a backup gateway or reconnects the primary gateway additionally to use this feature the peer device at the secondary gateway address cannot be set to use a nailed up VPN connection the fallback check interval allows the administrator to set how often to check if the primary address is once again available the branch WSU's connection settings remain unchanged from our previous example here you can see examples of the VPN monitor when the main tunnel is active and when the main connection is down and failover occurs in the system logs you can see the zywall USG tried to reach the primary tunnel gateway at the appropriate check interval when it does you'll be able to check the VPN monitor and logs to see if the tunnel is able to successfully reconnect the primary gateway the fallback mechanism starts only when IPSec VPN failover has occurred and the gree option fallback to primary peer gateway when possible is enabled fallback mechanism stops when there is no active si binding with the VPN gateway or IPSec VPN fallback has already occurred nailed up should be disabled on the secondary peers eyewall USG otherwise even if fallback succeeds the secondary peers I while USG will initiate the tunnel all the time causing severe IPSec problems and loss of VPN connectivity end of module you

You May Also Like