Concepts, Interoperability and Diagnose of VPN. IPSEC / SSL Routing Concepts. Xtream Team México, Cd. De México.

Transcription

1 Concepts, Interoperability and Diagnose of VPN. IPSEC / SSL Routing Concepts Xtream Team México, Cd. De México.

2 Agenda IPSEC VPN Concepts Basic VPN Implementation. FortiOS IPSEC Implementation. Diagnose and Troubleshooting commands and its interpretation. Routing Dynamic Routing Static/Policy Routing

3 IPSEC VPN Concepts

4 What is a VPN? Acme Corp A VPN is a private connection over an open network A VPN includes authentication and encryption to protect data integrity and confidentiality VPN Acme Corp Site 2 VPN

5 Types of VPNs Remote Access VPN Provides access to internal corporate network over the Internet Reduces long distance, modem bank, and technical support costs Corporate Site

6 Types of VPNs Remote Access VPN Site-to-Site VPN Connects multiple offices over Internet Reduces dependencies on frame relay and leased lines Corporate Site Branch Office Acme Corp Site 2

7 Types of VPNs Remote Access VPN Site-to-Site VPN Extranet VPN Provides business partners access to critical information (leads, sales tools, etc) Reduces transaction and operational costs Partner 1 Corporate Site Partner 2 Acme Corp Site 2

8 Types of VPNs Remote Access VPN Site-to-Site VPN Extranet VPN Client/Server VPN Protects sensitive internal communications Most attacks originate within an organization Application Servers Clients with Sensitive Information

9 Why Use Virtual Private Networks? More flexibility More scalability Add new sites, users quickly Scale bandwidth to meet demand

10 Why Use Virtual Private Networks? More flexibility More scalability Lower costs Reduced frame relay/leased line costs Reduced long distance Reduced equipment costs (modem banks,csu/dsus) Reduced technical support

11 Components of a VPN Encryption Message authentication Entity authentication Key management

12 Internet Protocol Security (IPSec) Layer 3 protocol for remote access, intranet, and extranet VPNs Internet standard for VPNs Provides flexible encryption and message authentication/integrity Includes key management

13 Components of an IPSec VPN Encryption Message Authentication Entity Authentication Key Management DES, 3DES, and more HMAC-MD5, HMAC- SHA-1, or others Digital Certificates, Shared Secrets,Hybrid Mode IKE Internet Key Exchange (IKE), Public Key Infrastructure (PKI) All managed by security associations (SAs( SAs)

14 Security Associations An agreement between two parties about: Authentication and encryption algorithms Key exchange mechanisms And other rules for secure communications Security associations are negotiated at least once per session possibly more often for additional security

15 Encryption Explained Used to convert data to a secret code for transmission over an untrusted network Clear Text The cow jumped over the moon Encryption Algorithm Encrypted Text 4hsd4e3mjvd3sd a1d38esdf2w4d

16 Symmetric Encryption Same key used to encrypt and decrypt message Faster than asymmetric encryption Used by IPSec to encrypt actual message data Examples: DES, 3DES, RC5, Rijndael Shared Secret Key

17 Asymmetric Encryption Different keys used to encrypt and decrypt message (One public, one private) Provides non-repudiation of message or message integrity Examples include RSA, DSA, SHA-1, MD-5 Bob Alice Alice Public Key Encrypt Alice Private Key Decrypt

18 Key Management Shared Secret Simplest method; does not scale Two sites share key out-of-band (over telephone, mail, etc) Public Key Infrastructure Provides method of issuing and managing public/private keys for large deployments Internet Key Exchange Automates the exchange of keys for scalability and efficiency

19 What are Keys? An Encryption Key is: A series of numbers and letters used in conjunction with an encryption algorithm to turn plain text into encrypted text and back into plain text The longer the key, the stronger the encryption

20 What is Key Management? A mechanism for distributing keys either manually or automatically Includes: Key generation Certification Distribution Revocation

21 Internet Key Exchange (IKE) Automates the exchange of security associations and keys between two VPN sites IKE provides: Automation and scalability Improved security Hybrid IKE Encryption keys be changed frequently Proposed standard designed by Check Point Allows use of existing authentication methods

22 Digital Certificates and Public Key Infrastructure A digital certificate: Contains a person s or entity s public key Enables safe distribution of public keys Is signed by a Certificate Authority s private key Verifies identity through trusted third party My Certificate: Name: Bob Organization: Fortinet Public Key: lk393l430fksffj398sdf1f594ier933d34w435d CA: xxx.xxx.xxx.xxx and more

23 Basic IPSEC Implementation

24 An IPSec Session: Putting It All Together Bob attempts to connect to corporate server Certificate Authority

25 An IPSec Session: Putting It All Together Bob attempts to connect to corporate server VPN gateway and VPN client on Bob s computer use IKE to: Verify VPN gateway s and Bob identities through digital certificates Establish security associations (keys and algorithms) for communications Certificate Authority

26 An IPSec Session: Putting It All Together Bob attempts to connect to corporate server VPN gateway and VPN client on Bob s computer use IKE to: Verify VPN gateway s and Bob identities through digital certificates Establish security associations (keys and algorithms) for communications An encrypted tunnel is established between Bob and VPN Gateway Certificate Authority

27 An IPSec Session: Putting It All Together Bob attempts to connect to corporate server VPN gateway and VPN client on Bob s computer use IKE to: Verify VPN gateway s and Bob identities through digital certificates Establish security associations (keys and algorithms) for communications An encrypted tunnel is established between Bob and VPN Gateway Bob can now retrieve his Certificate Authority

28 Deploying a VPN: Questions to Ask Access control of VPN traffic Protecting remote access clients Providing Quality of Service (QoS) to VPN traffic

29 Different Types of VPN/Firewall Topologies Firewall VPN VPN device is vulnerable to attack eg. denial of service VPN Firewall Two connections to the firewall for every communication request VPN Bypasses security policy Denial of service Firewall Only integrated VPN/firewall solutions can deliver full access control and consistent security policy enforcement

30 Protecting Remote Access VPNs The Problem: Remote access VPN clients can be hijacked Allows attackers into internal network The Solution: Centrally managed personal firewall on VPN clients Certificate Authority Cable or xdsl Attacker

31 Providing VPN QoS The Problem: Discretionary traffic (web surfing, Internet radio) degrades performance of mission critical VPN traffic The Solution: Complete Content Protection to apply security policy to the traffic and Traffic Shaping. Use of Policy Routing to distribute the load share among two or more Internet links.

32 Summary Virtual Private Networks have become mission-critical applications IPSec is the leading protocol for creating enterprise VPNs Provides encryption, authentication, and data integrity Organizations should look for: Integrated firewalls and VPNs Centralized management of VPN client security A method to provide VPN QoS

33 FortiOS IPSEC Implementation

34 FortiOS IPSEC Implementation On this training we will not discuss how to configure an IPSEC VPN connection, we will discuss the steps of doing it. Based on the previous explanation, there are three Pseudo Steps on an IPSEC VPN Connection: Phase 1 Phase 2 IP Policy

35 IPSEC Phase 1 The phase 1 is the Asymmetric Encryption part of the negotiation to establish a Security Association. In the FortiOS the DH (Diffie-Hellman per its creators) group is the actual key length to use a public and private key so the peers can identify and authenticate themselves. In this phase the peers use the Pre-shared key or the certificates to authenticate. After this they create a DES, 3DES or AES SYMMETRIC Key to encrypt the following communication that they are going to make. Why did they changed from a symmetric communication to an Asymmetric communication? Because the Symmetric communication is computationally faster.

36 IPSEC Phase 2 Once the Phase 1 is finished, the phase 2 negotiation starts. On this phase the gateway are authenticated, now they want to specify the encryption key that they are going to use to establish the security association and the communication tunnel. Once they have agreed on the key, the peers send the networks which traffic will be encrypted. If the networks that will be encrypted from each peer match with the configuration on both peers*, the VPN tunnel is established and a Security Association (SA) is created. * These Networks that will be encrypted are usually known as the Encryption Domain.

37 IPSEC FortiOS Implementation What have just happened is that an SA has been created and the tunnel is ready to transfer information. How does a tunnel works? Once a packet is being processed on the IP Stack, the packet is received by the NIC. The packet is then passed to the IP protocol stack of the FortiOS. If the packet has a destination IP that belongs to a network on the encryption domain, the original packet is encapsulated on a NEW IP packet. The packet is then sent to the remote gateway. The remote gateway receives the packet de-encapsulates it and sent to the local network.

38 IPSEC FortiOS Implementation Example of Encapsulated packet.

39 IPSEC FortiOS Implementation Behind the curtains, the FortiOS has defined the SA tunnel and with this, a Virtual Route that specifies that the Networks that belong to the Encryption Domain will be routed through the tunnel and not using the regular routes on the FortiOS. This means that if a packet contains a destination network that belong to a remote network of an existing VPN tunnel, the packet will be encapsulated and sent over the tunnel. The packet is received at the remote gateway and if it matches the VPN policy, the packet is decrypted and sent to the destination per the policy.

40 IPSEC FortiOS Implementation We stated that the traffic will be allowed if the policy permits the communication. This means the tunnel is established, and some packets arrive to the Fortigate encrypted. The packets are decrypted and THEN they are evaluated by the Fortigate Firewall Policies. Remember that we can control which networks can communicate between the units, along with the protocol and ports. And we can also add a new layer of access control by specifying the Protocol, TCP or UDP port that the remote peer can connect to the local peer(s) this in an independent fashion of what the encryption domain actually specifies. This is very useful if your customer is a big entrerprise and they want to assure to the best probability that the communication is limited to the strictly required communication.

41 IPSEC FortiOS Implementation We have explained so far the Tunnel Mode IPSEC implementation. On the FortiOS there is also a Interface mode IPSEC configuration. The main differences are: The Interface mode is an actual VIRTUAL interface that is created on the interface that receives or send the encrypted packets. The Interface mode VPN tunnel allows the sending and receiving of routing specific packets like Multicast, or dynamic routing protocols like RIP, OSPF or BGP. The Interface mode allows the creation of redundant VPN tunnels as a simple static route scenario.

42 IPSEC FortiOS Implementation The FortiOS 3.0 Changed the way several configuration of VPN tunnels: The most significant one is the fact that on the FortiOS 2.8 the encryption domain was usually defined by the Firewall policy and now its defined on the Phase 2 definition. A common question is How can I define more than 1 network as the encryption domain? The answer is: As in the previous version you can create a group of networks and the define this groups as your source or destination encryption domain. Be aware that the only way to define a group as Encryption domain for FortiOS 3.0 MR3 and lower is using the CLI. The Ping server is now removed. Its functionality was replaced by the Autokey KeepAlive parameter. With this enable the FortiOS will always try to keep the tunnel up, no matter if there is no traffic flowing through the tunnel.

43 IPSEC FortiOS Implementation. TIP: When you have 3 or more IPSEC tunnels, it might happen to you that a remote peer is connected through a tunnel that does not corresponds to the source. This happens because usually the user or partner uses the same pre-shared key for all the tunnels. And as this is the key to encrypt the communications to the tunnel, the FortiOS have no way to identify which packet belong to which local tunnel. This can be solved by using local ID. By using cross matched local IDs, the Fortigate will know which tunnel a packet belongs to. It is recommended to use Aggressive mode encryption when creating more than 2 VPN tunnels on the FortiOS.

44 IPSEC FortiOS Implementation Bonus questions! What is the meaning and usage of the Inbound NAT and Outbound NAT options on the VPN policy? What is the meaning and usage of proxy ARP for a VPN implementation? What to do when there is an overlapping scenario for VPN?

45 Diagnose and Troubleshooting commands and its interpretation.

46 Diagnose commands for VPN. In the FortiOS there are some special commands specially designed to troubleshoot and provide maintenance to the IPSEC VPN tunnels. The Following command branches are designed to this purposes: Diag vpn: - vpn -- gw -- list - flush - routes +- config - ipsec -- status - xstatus +- debug -- debug (0) - tunnel -- down -- phase2 -- phase1 (0) - up -- phase2 -- phase1 (0) - list -- name +- number -- <begin-index> -- <end-index> (0) - dialup-list - reset - flush - delinbsa -- <name> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> (0) - deloutbsa -- <name> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> (0) - dumpsa +- stat -- flush - concentrator -- list - l2tp -- status +- pptp -- status

47 Diagnose command for VPN The following commands are for VPN debugging only. Diag debug application ike <Integer> <IP!> Diag debug application ike The following is an example of usage and explanation of both diag debug/vpn branches for VPN.

48 Diagnose commands for VPN The diag vpn branch: NETCHDT # diag vpn concentrator gw ipsec l2tp pptp tunnel IPsec concentrator This is the branch to look on how are the concentrators working on the FG. IPsec gateway All the options for gateway (IPSEC phase 1) management. general IPsec Status of the IPSEC crypto devices. vpn l2tp The l2tp status output. DO NOT USE L2TP VPNs vpn pptp The pptp status output. DO NOT USE PPTP VPNs IPsec tunnel All options for tunnel (IPSEC phase 2) management.

49 Diagnose commands for VPN Once the tunnel has been correctly configured, please be advised of the following: The tunnel might be up, but the traffic is not flowing: Careful of the network masks, are the networks correctly configured on the policy? This is one of the common mistakes when configuring an IPSEC VPN. The tunnel configuration is most of the time OK, but be careful with stale session that might go through another way BEFORE the tunnel was created. The tunnel configuration might have changed, but the Gateway configuration might be the same and that could be a reason some traffic might not be flowing correctly.

50 Diagnose commands for VPN The diagnose vpn gw branch. This command branch function is to control the establishment of the Phase 1 negotiations. This commands options are: ChidoSL # diag vpn gw config config» This command allows to specify advanced parameters to the GW. UNUSED flush flush» This commands flushes all IPSEC phase 1 negotiations that are connected. list list» Shows the gateways that are connected. routes routes» UNUSED

51 Diagnose commands for VPN diag vpn gw list ChidoSL # GW_Xtreme_ > :500 dpd-ok=1 The name of the GW, as the FortiOS sees it. Note the Secuence number state=5 connected=yes rekey-time=24991 cookies=33b6c25f /b0b16fbb04b2ede8 state=4 connected=yes rekey-time=24961 cookies=2f50ab e3/0b50051fb9d442e0 This is the Diag rekey vpntime gw flush specified on the phase 1 definition This is the SPI cookie for the specified GW. (For Flushes all the GW (phase 1) negotiations on the FortiOS. This is the most commons solutions of the I changed the Information pre-shared key only) of X tunnel with for example a Cisco unit, and the tunnel still doesn t come up correctly. This is the command to go when you want to be sure that a complete ipsec negotiation must be made. CAREFUL, ALL the tunnels will be affected by this command, unless you specify the name of the gw as a last argument. I. E.: diag vpngw flush my_gw_1

52 Diagnose commands for VPN ChidoSL # diag vpn tunnel delinbsa remove tunnel sa deloutbsa dialup-list Not recommended to use remove tunnel sa Not recommended to use list dialup tunnel Dumps the list of the dial-up tunnels that are connected at a given time to the FG. down Shut down tunnel Forces a tunnel (phase 2) stop. It is the equivalent to the GUI down command dumpsa dump all sa flush list reset stat up Not recommended to use flush tunnel SAs This commands can force a hard cleanup of ALL the IPSEC tunnels up. It can be used to close only a named tunnel. list all tunnel flush tunnel SAs and reset NAT-T and DPD configuration Not recommended to use tunnel statistic info Not recommended to use Activate tunnel Forces a tunnel (phase 2) start. It is the equivalent to the GUI up command

53 Diagnose commands for VPN This is a tunnel that is correctly configured but unconnected: ChidoMX # diag vpn tunnel list This is the phase 1 name list all ipsec tunnel in vd name=gw_xtreme_ :0-> :0 lgwy=dyn tun=tunnel mode=auto bound_if=3 proxyid_num=1 child_num=0 refcnt=6 ilast=2 olast=2 stat: rxp=21 txp=7 rxb=2544 txb=420 dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=1236 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=tunel_xtreme_1 proto=0 sa=0 ref=1 auto_negotiate=0 src: / (4):0 dst: / (4):0 Type of tunnel Bound Interface? IMPORTANT! These are the related GWs IPS DPD Detection status Nat Transversal Status These are the actual quick mode selectors or networks that form the encryption domain Proxy ID Identication, AKA: Encryption domain or phase 2 selection

54 Diagnose commands for VPN This is correctly configured VPN tunnel but this time connected. ChidoSL # diag vpn tunnel list Statistics: list all ipsec tunnel in vd Received packets, rxp name=gw_xtreme_ :0-> :0 Transmitted packets, lgwy=dyn txp tun=tunnel mode=auto bound_if=3 proxyid_num=1 child_num=0 refcnt=7 ilast=0 olast=0 stat: rxp=26 txp=12 rxb=3104 txb=720 Received bytes, rxb dpd: mode=active on=1 idle=5000ms retry=3 Transmitted count=0 seqno=1770 bytes, txb SA status, 0 or 1 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=tunel_xtreme_1 proto=0 sa=1 ref=2 auto_negotiate=0 SA expire src: / (4):0 in second MTU size dst: / (4):0 SA: ref=3 options= e in type=00 bytes soft=0 mtu=1436 expire=1743 replaywin=1024 seqno=3 life: type=01 bytes=0/0 timeout=1750/1800 dec: spi=f20ca131 esp=3des key=24 13a61bcf3d16ad918def5d197e25d155eb352eb3e8e385ea ah=sha1 key=20 79ae86e3ccf1aeac8c53a193ef6603c580de5c1d enc: spi= esp=3des key=24 209dec1ef5a70d893635ff99034ef e5d883a459e ah=sha1 key=20 4cfc22406d65d0ec84355e8a5458a99655b17b42 Decryption keys, dec Encription keys, enc SPI encryption algorithm and AH hashing algorithm Encryption key and hash, changes over time

55 Diagnose commands for VPN The advanced troubleshooting command for IPSEC VPN tunnel negotiations is: Diag debug application ike 2 It must be invoked before or after the command: Diag debug enable.» If this step is missed, the debug output WILL NOT BE SHOWN in the screen. This command outputs the whole IPSEC negotiation on the screen, either via telnet, ssh or console connection. This command output will not count as input to the FOS, so after a while of no activity even that there is packet output, the communication with the FG might time out. Solution: press <ENTER> frequently while using this command.

56 VPN Topology We are going to use the following topology conventions. Any of you should have two Fortigates, a couple per person or at least 2 FG for a two people team. All of you should have your name tag with a number on it. This would be used for IP conventions they should be as follows. When refering to a X you should replace this for your number. Example: X.0 would look like where 1 is your assigned number When refering to a X0 you should replace this for your number and add a 0 to it. Example: X0.0 would look like where 1 was your assigned number plus the 0.

57 VPN Topology for local VPN tests The Network diagram for the local FG to FG VPN lab is: Local Network: X.0/24 Host: X1 FG: X.254 A Local Network: X.0/24 Host: X.1 FG: X.254 B Routing network FortiGate A: X0.1 FortiGate B: X0.254

58 Diagnose commands for VPN The phase 1 configuration of GW_A is: ChidoSL # show vpn ipsec phase1 config vpn ipsec phase1 edit "GW_Xtreme_1" set interface "wan1" set dpd enable set nattraversal enable set proposal 3des-sha1 3des-md5 set mode aggressive set remote-gw set psksecret ENC DMBJa4L1j/g1sVDcUJOA5ljNyH3tKcRrLjzWrwYY8bNkZbNRu5djZR7gx/V1 XyKjNnfpQiChln5K+LzcwQ+KlsE/dlFjQLoLs8ZFC1jL9PEVF2we next end

59 Diagnose commands for VPN The phase 2 configuration of GW_A is: ChidoSL # show vpn ipsec phase2 config vpn ipsec phase2 edit "tunel_xtreme_1" set pfs enable set phase1name "GW_Xtreme_1" set proposal 3des-sha1 3des-md5 set replay enable set src-subnet set dst-subnet next end

60 Diagnose commands for VPN The Phase 1 configuration for GW_B edit "GW_Xtreme" set interface "wan1" set nattraversal enable set proposal 3des-sha1 3des-md5 set mode aggressive set remote-gw set psksecret ENC nkpdeszym29h+xgms5h+js31zsguqwoy4kne5pxvje0j cwiwcsb7+l7jzj19hmkodwbhqmzdy0pqmqsjxzy9b0xlrz tm+ev+wlfqfiymkahwdlj/ next

61 Diagnose commands for VPN The phase 2 configuration for GW_B is: edit "tunel_xtreme" set pfs enable set phase1name "GW_Xtreme" set proposal 3des-sha1 3des-md5 set replay enable set src-subnet set dst-subnet next

62 Diagnose commands for VPN 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0x GWs, IF Index len=460 0:GW_Xtreme_1: new connection. 0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID 0:GW_Xtreme_1:16: responder: aggressive mode get 1st message... 0:GW_Xtreme_1:16: parse all vendor ids... 0:GW_Xtreme_1:16: found DPD v2 0:GW_Xtreme_1:16: found DPD v2 (Fgt) 0:GW_Xtreme_1:16: found Fortigate DPD 0:GW_Xtreme_1:16: found non-keepalive fortigate 0:GW_Xtreme_1:16: found NAT-T v3 0:GW_Xtreme_1:16: found NAT-T v0/1 0:GW_Xtreme_1:16: negotiation result 0:GW_Xtreme_1:16: proposal id = 1: 0:GW_Xtreme_1:16: protocol id = ISAKMP: Dead Peer Detection? Nat Transversal? IPs of the related Type of Encryption Encryption negotiation: IKE. 3DES, SHA. Auth, Pre-shared Key. Diffie Hellman Group, 5 (1536 Bytes) 0:GW_Xtreme_1:16: trans_id = KEY_IKE. 0:GW_Xtreme_1:16: encapsulation = IKE/none 0:GW_Xtreme_1:16: type=oakley_encrypt_alg, val=3des_cbc. 0:GW_Xtreme_1:16: type=oakley_hash_alg, val=sha. 0:GW_Xtreme_1:16: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:16: type=oakley_group, val= :GW_Xtreme_1:16: phase1 lifetimes= :GW_Xtreme_1:16: sending DPD VID payloads... Type of Nat 0:GW_Xtreme_1:16: sending FGT DPD VID payloads... Transversal negotiation 0:GW_Xtreme_1:16: Sending VID payload... 0:GW_Xtreme_1:16: sending NATT VID payload (draft3)... 0:GW_Xtreme_1: put connection to natt list...ip= GW_Xtreme_1: Responder: sent aggressive mode message #1 (OK) 0:GW_Xtreme_1:16: send IKE Packet(STF_REPLY): :500(if3) -> :500, len=480 0:GW_Xtreme_1:16: retransmit timeout=6. Send the negotiation result packet, outboud IF, retransmit timeout for an answer Special payload IDs Aggressive mode message #1 OK!

63 Diagnose commands for VPN This output from GW A on the VPN connection. 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0xE D550F080 Received second len=132 response from the remote peer 0::16: received payloads HASH Notif 0:GW_Xtreme_1:16: responder: aggressive mode get 2nd response... 0:GW_Xtreme_1:16: using IPS_NAT_MODE_NONE. 0:GW_Xtreme_1:16: processing INITIAL-CONTACT 0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1:16: processed INITIAL-CONTACT Received another packet 0:GW_Xtreme_1:16: set phase1 state timeout=28800 Started initial contact, flushed state, initial contact OK. GW_Xtreme_1: Responder: parsed aggressive mode message #2 (DONE) Aggressive mode (phase 1) message #2 OK. Keylife in seconds

64 Diagnose commands for VPN This is a typical Dead Peer Detection Packet after the initial contact. 0: comes :500-> :500,ifindex=3... 0: Exchange=5 Message=0x8D78FB04 len=84 0: checking GW_Xtreme_ > :500 0:GW_Xtreme_1: phase1 found 0:GW_Xtreme_1:16: received payloads HASH Notif 0:GW_Xtreme_1:16: received protected info 0:GW_Xtreme_1:16: send IKE Packet(DPD response): :500(if3) -> :500, len=84 An encrypted notification payload A Dead Peer Detection RESPONSE packet is sent over the phase 1 negotiation

65 Diagnose commands for VPN Phase 2 negotiation on GW_A. 0: comes :500-> :500,ifindex=3... 0: Exchange=32 Message=0x9B2E4B90 len=396 0: checking GW_Xtreme_ > :500 0:GW_Xtreme_1: phase1 found 0:GW_Xtreme_1:16: received payloads HASH SA NONCE KE ID ID 0:GW_Xtreme_1:16: responder received first quick-mode message 0:GW_Xtreme_1:17: peer proposal is: peer: / , me: / , ports=0/0, protocol=0/0 0:GW_Xtreme_1:17: trying tunel_xtreme_1 The policy is matched to a given phase 2 0:GW_Xtreme_1:17: matched phase2 tunel_xtreme_1 0:GW_Xtreme_1:17: autokey tunel_xtreme_1 0:GW_Xtreme_1:17: negotiation result 0:GW_Xtreme_1:17: proposal id = 1: 0:GW_Xtreme_1:17: protocol id = IPSEC_ESP: The packets always come from a remote peer to the central 0:GW_Xtreme_1:17: trans_id = ESP_3DES. 0:GW_Xtreme_1:17: encapsulation = ENCAPSULATION_MODE_TUNNEL 0:GW_Xtreme_1:17: type=auth_alg, val=sha1. 0:GW_Xtreme_1:17: set pfs=1536 0:GW_Xtreme_1:17: using tunnel mode. 0:GW_Xtreme_1:17: responder quick-mode set pfs= :GW_Xtreme_1:17: quick-mode IDci type=4, len=8, chunk=c0a8aa00ffffff00 0:GW_Xtreme_1:17: quick-mode IDcr type=4, len=8, chunk=c0a81100ffffff00 Tunnel mode, PFS, group 5 Quick mode negotiation (phase 2) IKE reply to peer for phase GW_Xtreme_1: 2, Responder: sent quick mode message #1 (OK) message 0:GW_Xtreme_1:17: 1. send IKE Packet(STF_REPLY): :500(if3) -> :500, len=356 Retransmit 0:GW_Xtreme_1:17: retransmit timeout=6. timeout. The available GW is checked Here the peers exchange their respective encryption domains. Peer proposal is the remote GWs proposal, me is what the local FG is expecting as Encryption domain Encryption selection: ESP: 3DES, Auth: SHA-1. Tunnel mode VPN Phase 2 message #1 OK.

66 Diagnose commands for VPN Matched a phase 1, go to This is the second phase 2 message next step to the GW_A. 0: comes :500-> :500,ifindex=3... 0: Exchange=32 Message=0x9B2E4B90 len=52 0: checking GW_Xtreme_ > :500 status 0:GW_Xtreme_1: phase1 found 0:GW_Xtreme_1:17: received payloads HASH 0:GW_Xtreme_1:17: replay protection enabled 0:GW_Xtreme_1:17: set sa life soft seconds=1750. The SA is now established Replay protection Timers for the SA, soft and high 0:GW_Xtreme_1:17: set sa life hard seconds= :GW_Xtreme_1:17: add SA #src=1 #dst=1 0:GW_Xtreme_1:17: src / :GW_Xtreme_1:17: dst / :GW_Xtreme_1:17: installed SA: SPIs=f20ca133/ :GW_Xtreme_1:17: sending SNMP tunnel UP trap for tunel_xtreme_1 0:GW_Xtreme_1:17: responder quick-mode done! The SA is installed in the kernel The Encryption domain is reconfirmed The SNMP trap for tunnel up is sent GW_Xtreme_1: Responder: parsed quick mode message #2 (DONE) 0:GW_Xtreme_1:17: expire timeout=120. The local FG unit has parsed the quick message #2 correctly. The tunnel as the FortiOS is concerned is now created and fully operational

67 Diagnose commands for VPN This is from GW_B to the central GW_A. This time YOU will be doing the analysis. This the KEY WORD. Why? 0:GW_Xtreme: new connection. 0:GW_Xtreme:43: initiator: aggressive mode is sending 1st message... 0:GW_Xtreme:43: initiator: aggressive mode set DH= :GW_Xtreme:43: sending DPD VID payloads... 0:GW_Xtreme:43: sending FGT DPD VID payloads... 0:GW_Xtreme:43: Sending VID payload... 0:GW_Xtreme:43: sending NATT VID payload (draft3)... 0:GW_Xtreme:43: sending NATT VID payload (draft3 The Aggressive and draft1)... mode message #1 is SENT by this unit. Look for the 0:GW_Xtreme:43: send IKE Packet(aggr_outI1): :500(if3) -> KEY word :500, len=460 GW_Xtreme: Initiator: sent aggressive mode message #1 (OK) 0:GW_Xtreme:43: retransmit timeout=6.

68 Diagnose commands for VPN 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x3D90E4DBCE3E4416 R_COOKIE=0x2BB0EBFC3FD1D28B len=480 0: checking GW_Xtreme > :500 0:GW_Xtreme: phase1 found 0:GW_Xtreme:43: received payloads SA KE NONCE ID VID VID VID VID VID HASH 0:GW_Xtreme:43: initiator: aggressive mode get 1st response... 0:GW_Xtreme:43: negotiation result 0:GW_Xtreme:43: proposal id = 1: 0:GW_Xtreme:43: protocol id = ISAKMP: 0:GW_Xtreme:43: trans_id = KEY_IKE. 0:GW_Xtreme:43: encapsulation = IKE/none 0:GW_Xtreme:43: type=oakley_encrypt_alg, val=3des_cbc. 0:GW_Xtreme:43: type=oakley_hash_alg, val=sha. 0:GW_Xtreme:43: type=auth_method, val=preshared_key. 0:GW_Xtreme:43: type=oakley_group, val= :GW_Xtreme:43: phase1 lifetimes= :GW_Xtreme:43: negotiate success 0:GW_Xtreme:43: parse all vendor ids... 0:GW_Xtreme:43: found DPD v2 0:GW_Xtreme:43: found DPD v2 (Fgt) 0:GW_Xtreme:43: found Fortigate DPD If so, why? 0:GW_Xtreme:43: found non-keepalive fortigate 0:GW_Xtreme:43: found NAT-T v3 0:GW_Xtreme:43: using IPS_NAT_MODE_NONE. 0:GW_Xtreme:43: Sending initial contact 0:GW_Xtreme:43: set phase1 state timeout=28800 GW_Xtreme: Initiator: sent aggressive mode message #2 (DONE) 0:GW_Xtreme:43: send IKE Packet(STF_REPLY): :500(if3) -> :500, len=132 This is exactly the negotiation Information that was analyzed On the central Gateway. Can you see differences?

69 Diagnose commands for VPN What are the key elements of these messages: Key ITEMS: o Gateways IPs. 0:GW_Xtreme:tunel_Xtreme: IPsec SA connect > :500, natt_mode=0 o PFS status 0:GW_Xtreme: using existing connection, dpd_fail=0 0:GW_Xtreme: found phase2 tunel_xtreme o Quick mode selectors 0:GW_Xtreme: IPsec SA connect > :500 negotiating 0:GW_Xtreme:44: initiator quick-mode set pfs= :GW_Xtreme:44: try to negotiate with 1800 life seconds. 0:GW_Xtreme:44: initiate an SA with selectors: / > / , ports=0/0, protocol=0/0 0:GW_Xtreme:44: send IKE Packet(quick_outI1): :500(if3) -> :500, len=396 GW_Xtreme: Initiator: sent quick mode message #1 (OK) 0:GW_Xtreme:44: retransmit timeout=6.

70 Diagnose commands for VPN 0: comes :500-> :500,ifindex=3... 0: Exchange=32 Message=0x6C777C6C len=356 0: checking GW_Xtreme > :500 0:GW_Xtreme: phase1 found 0:GW_Xtreme:44: received payloads HASH SA NONCE KE ID ID 0:GW_Xtreme:44: initiator quick-mode received first response 0:GW_Xtreme:44: negotiation result 0:GW_Xtreme:44: proposal id = 1: 0:GW_Xtreme:44: protocol id = IPSEC_ESP: 0:GW_Xtreme:44: trans_id = ESP_3DES. 0:GW_Xtreme:44: encapsulation = ENCAPSULATION_MODE_TUNNEL 0:GW_Xtreme:44: type=auth_alg, val=sha1. 0:GW_Xtreme:44: using tunnel mode. 0:GW_Xtreme:44: negotiate success 0:GW_Xtreme:44: initiator install SA 0:GW_Xtreme:44: replay protection enabled 0:GW_Xtreme:44: set sa life soft seconds= :GW_Xtreme:44: set sa life hard seconds= :GW_Xtreme:44: add SA #src=1 #dst=1 0:GW_Xtreme:44: src / :GW_Xtreme:44: dst / :GW_Xtreme:44: installed SA: SPIs= a/f20ca134 0:GW_Xtreme:44: sending SNMP tunnel UP trap for tunel_xtreme GW_Xtreme: Initiator: sent quick mode message #2 (DONE) 0:GW_Xtreme:44: expire timeout=120. 0:GW_Xtreme:44: send IKE Packet(STF_REPLY): :500(if3) -> :500, len=52 Identify key items

71 Other VPN scenarios What about an XAuth negotiation scenario? 0: comes :47340-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x800B09EAE7EDBE45 R_COOKIE=0x len=512 0:Dialup_Xauth: new connection. 0:Dialup_Xauth:0: received payloads SA KE NONCE ID VID VID VID VID VID 0:Dialup_Xauth:30: responder: aggressive mode get 1st message... 0:Dialup_Xauth:30: parse all vendor ids... 0:Dialup_Xauth:30: found DPD v2 0:Dialup_Xauth:30: found DPD v2 (Fgt) 0:Dialup_Xauth:30: found FortiClient v1 0:Dialup_Xauth:30: found NAT-T v3 0:Dialup_Xauth:30: found NAT-T v0/1 0:Dialup_Xauth:30: negotiation result 0:Dialup_Xauth:30: proposal id = 1: 0:Dialup_Xauth:30: protocol id = ISAKMP: Can you identify the differences on the IPSEC negotiation? 0:Dialup_Xauth:30: trans_id = KEY_IKE. 0:Dialup_Xauth:30: encapsulation = IKE/none 0:Dialup_Xauth:30: type=oakley_encrypt_alg, val=3des_cbc. 0:Dialup_Xauth:30: type=oakley_hash_alg, val=md5. 0:Dialup_Xauth:30: type=auth_method, val=preshared_key. 0:Dialup_Xauth:30: type=oakley_group, val= :Dialup_Xauth:30: phase1 lifetimes= :Dialup_Xauth:30: sending DPD VID payloads... 0:Dialup_Xauth:30: sending FGT DPD VID payloads... 0:Dialup_Xauth:30: Sending VID payload... 0:Dialup_Xauth:30: sending NATT VID payload (draft3)... 0:Dialup_Xauth: put connection to natt list...ip= Dialup_Xauth: Responder: sent aggressive mode message #1 (OK) 0:Dialup_Xauth:30: send IKE Packet(STF_REPLY): :500(if3) -> :47340, len=468 0:Dialup_Xauth:30: retransmit timeout=6.

72 Other VPN Scenarios Continuing with the XAuth Scenario. 0: comes :47407-> :4500,ifindex=3... 0: Exchange=4 I_COOKIE=0x800B09EAE7EDBE45 R_COOKIE=0xA1F94BDC8A9F401B len=116 0::30: received payloads HASH Notif 0:Dialup_Xauth:30: responder: aggressive mode get 2nd response... 0:Dialup_Xauth:30: using IPS_NAT_MODE_SILENT. 0:Dialup_Xauth:30: processing INITIAL-CONTACT 0:Dialup_Xauth: flushing Could you identify the differences 0:Dialup_Xauth: flushed In the IPSEC negotiation? 0:Dialup_Xauth:30: processed INITIAL-CONTACT 0:Dialup_Xauth:30: set phase1 state timeout=28800 Dialup_Xauth: Responder: parsed aggressive mode message #2 (DONE) 0:Dialup_Xauth: adding new dialup tunnel for : :Dialup_Xauth_0: added new dialup tunnel for : :Dialup_Xauth_0:30: initiating Xauth. 0:Dialup_Xauth_0:31: send IKE Packet(xauth): :4500(if3) -> :47407, len=68 Dialup_Xauth_0: Initiator: sent xauth mode message #1 (OK) 0:Dialup_Xauth_0:31: retransmit timeout=6.

73 Other VPN Scenarios Continuing with the XAuth Negotiation. 0: comes :47407-> :4500,ifindex=3... 0: Exchange=32 Message=0xC1A50450 len=476 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found What is the important Information in this Step of the negotiation? 0: comes :47407-> :4500,ifindex=3... 0: Exchange=6 Message=0xCC9D3947 len=84 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:31: received payloads HASH PSEUDO_NATD 0:Dialup_Xauth_0:31: XAUTH received 1st reply 0:Dialup_Xauth_0:31: expire timeout=120. 0:Dialup_Xauth_0: XAUTH authenticating user="test-mx" password="fortinet" 0:Dialup_Xauth_0: xauth succeeded 0:Dialup_Xauth_0:32: send IKE Packet(xauth): :4500(if3) -> :47407, len=60 Dialup_Xauth_0: Initiator: sent xauth mode message #2 (OK) 0:Dialup_Xauth_0:32: retransmit timeout=6.

74 Other VPN scenarios The XAuth negotiation continues 0: comes :47407-> :4500,ifindex=3... 0: Exchange=32 Message=0xC1A50450 len=476 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:30:? received payloads HASH SA NONCE KE ID ID 0:Dialup_Xauth_0:30: responder received first quick-mode message 0:Dialup_Xauth_0:33: peer proposal is: peer: , me: / , ports=0/0, protocol=0/0 0:Dialup_Xauth_0:33: trying Tunel_Xauth 0:Dialup_Xauth_0:33: matched phase2 Tunel_Xauth 0:Dialup_Xauth_0:33: dialup Tunel_Xauth 0:Dialup_Xauth_0:33: negotiation result 0:Dialup_Xauth_0:33: proposal id = 1: 0:Dialup_Xauth_0:33: protocol id = IPSEC_ESP: 0:Dialup_Xauth_0:33: trans_id = ESP_3DES. 0:Dialup_Xauth_0:33: encapsulation = UDP_ENCAPSULATION_MODE_TUNNEL 0:Dialup_Xauth_0:33: type=auth_alg, val=md5. 0:Dialup_Xauth_0:33: set pfs=1536 0:Dialup_Xauth_0:33: using udp tunnel mode. 0:Dialup_Xauth_0:33: responder quick-mode set pfs= :Dialup_Xauth_0:33: quick-mode IDci type=1, len=4, chunk=c0a8aa0c 0:Dialup_Xauth_0:33: quick-mode IDcr type=4, len=8, chunk=c0a81100ffffff00 Dialup_Xauth_0: Responder: sent quick mode message #1 (OK) 0:Dialup_Xauth_0:33: send IKE Packet(STF_REPLY): :4500(if3) -> :47407, len=348 0:Dialup_Xauth_0:33: retransmit timeout=6. Something interesting on this step?

75 Other VPN Scenarios And it goes on ;-) 0: comes :47407-> :4500,ifindex=3... 0: Exchange=5 Message=0x8E775B11 len=84 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:30: received payloads HASH Notif 0:Dialup_Xauth_0:30: received protected info Something interesting on this slide? 0: comes :47407-> :4500,ifindex=3... 0: Exchange=32 Message=0xC1A50450 len=476 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:33: Process retransmit... 0: comes :47407-> :4500,ifindex=3... 0: Exchange=6 Message=0xF49A9224 len=60 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:32: received payloads HASH PSEUDO_NATD 0:Dialup_Xauth_0:32: XAUTH received 2nd reply Dialup_Xauth_0: Initiator: parsed xauth mode message #2 (DONE) 0:Dialup_Xauth_0:32: expire timeout=120.

76 Other VPN Scenarios At last, the end of this IPSEC negotiation 0: comes :47407-> :4500,ifindex=3... 0: Exchange=32 Message=0xC1A50450 len=52 0: checking Dialup_Xauth_ > : :Dialup_Xauth_0: phase1 found 0:Dialup_Xauth_0:33: received payloads HASH 0:Dialup_Xauth_0:33: replay protection enabled 0:Dialup_Xauth_0:33: set sa life soft seconds= :Dialup_Xauth_0:33: set sa life hard seconds=1800. GOOD old Phase2 end 0:Dialup_Xauth_0:33: add SA #src=1 #dst=1 0:Dialup_Xauth_0:33: src / :Dialup_Xauth_0:33: dst / phase of the negotiation! 0:Dialup_Xauth_0:33: installed SA: SPIs=f20ca13c/1427bb6f 0:Dialup_Xauth_0:33: sending SNMP tunnel UP trap for Tunel_Xauth 0:Dialup_Xauth_0:33: responder quick-mode done! Any special on this negotiation step? Which part of the IPSEC negotation is? Something to note about it? Dialup_Xauth_0: Responder: parsed quick mode message #2 (DONE) 0:Dialup_Xauth_0:33: expire timeout=120.

77 Troubleshooting IPSEC Tunnels You are debugging a VPN tunnel that is not coming up, the error shown is: 0:GW_Xtreme_1:41: sending INFO message NO_PROPOSAL_CHOSEN to peer 0:GW_Xtreme_1:41: send IKE Packet(Info Mode): :500(if3) -> :500, len=68 0:GW_Xtreme_1:41: transmitted 68 bytes GW_Xtreme_1: Responder: parsed quick mode message #1 (ERROR) 0:GW_Xtreme_1:42: delete state

78 Troubleshooting IPSEC Tunnels Here Now is with is the the Phase the rest 1 phase negotiation: of the 2 negotiation: Phase 1 negotiation: ChidoSL # 0: comes :500-> :500,ifindex=3... 0: Exchange=4 comes :500-> :500,ifindex=3... I_COOKIE=0x50A45C98F220D747 R_COOKIE=0x len=460 0: checking GW_Xtreme_ > :500 0: Exchange=32 Message=0x5A779BDD len=396 0: comes :500-> :500,ifindex=3... What would be your immediate next step? 0:GW_Xtreme_1: checking GW_Xtreme_1 phase1 found > :500 0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID 0:GW_Xtreme_1: phase1 found 0:GW_Xtreme_1:41: responder: aggressive mode get 1st message... 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:41: Exchange=4 parse received all vendor I_COOKIE=0x50A45C98F220D747 payloads ids... HASH SA NONCE KE ID ID found DPD v2 R_COOKIE=0xF4D31A5BF23A3E1E Any idea on which len=132 step 0:GW_Xtreme_1:41: responder received first quick-mode message 0:GW_Xtreme_1:41: found DPD v2 (Fgt) 0:GW_Xtreme_1:41: What found would Fortigate DPD you require to troubleshoot? 0::41: protocol=0/0 received payloads HASH Notif 0:GW_Xtreme_1:41: found non-keepalive fortigate 0:GW_Xtreme_1:42: trying tunel_xtreme_1 the error is? 0:GW_Xtreme_1:41: found NAT-T v3 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: found matched NAT-T v0/1 phase2 tunel_xtreme_1 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: negotiation autokey result tunel_xtreme_1 0:GW_Xtreme_1:41: proposal id = 1: 0:GW_Xtreme_1:42: peer proposal is: peer: / , me: / , ports=0/0, 0:GW_Xtreme_1:41: responder: aggressive mode get 2nd response... 0:GW_Xtreme_1:41: using IPS_NAT_MODE_NONE. 0:GW_Xtreme_1:42: negotiation result 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: protocol proposal id = ISAKMP: id = 1: 0:GW_Xtreme_1:41: trans_id = KEY_IKE. 0:GW_Xtreme_1:42: protocol id = IPSEC_ESP: Where? 0:GW_Xtreme_1:41: encapsulation = IKE/none 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: type=oakley_encrypt_alg, trans_id = ESP_3DES. val=3des_cbc. 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: type=oakley_hash_alg, val=sha. 0:GW_Xtreme_1:41: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:41: ignored duplicated INITIAL-CONTACT. 0:GW_Xtreme_1:41: set phase1 state timeout=28800 encapsulation = ENCAPSULATION_MODE_TUNNEL 0:GW_Xtreme_1:42: type=auth_alg, Responder: val=sha1. parsed aggressive mode 0:GW_Xtreme_1:41: type=oakley_group, val= :GW_Xtreme_1:42: 0:GW_Xtreme_1:41: message set phase1 #2 pfs=1536 lifetimes=28800 (DONE) 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: sending using DPD tunnel VID payloads... mode. 0:GW_Xtreme_1:41: 0:GW_Xtreme_1:42: sending negotiation FGT DPD error VID payloads... 0:GW_Xtreme_1:41: Sending VID payload... 0:GW_Xtreme_1:41: sending NATT VID payload (draft3)... 0:GW_Xtreme_1:41: sending INFO message NO_PROPOSAL_CHOSEN to peer 0:GW_Xtreme_1:41: send IKE Packet(Info Mode): :500(if3) -> :500, len=68 0:GW_Xtreme_1: put connection to natt list...ip= GW_Xtreme_1: 0:GW_Xtreme_1:41: Responder: transmitted sent bytes aggressive mode message #1 (OK) 0:GW_Xtreme_1:41: Responder: send IKE Packet(STF_REPLY): :500(if3) parsed quick mode message -> :500, #1 (ERROR) len=480 0:GW_Xtreme_1:41: retransmit timeout=6. 0:GW_Xtreme_1:42: delete state

79 Troubleshooting IPSEC Tunnels 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x6934F521FC R_COOKIE=0x len=460 0:GW_Xtreme_1: new connection. 0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID 0:GW_Xtreme_1:64: responder: aggressive mode get 1st message... 0:GW_Xtreme_1:64: parse all vendor ids... 0:GW_Xtreme_1:64: found DPD v2 0:GW_Xtreme_1:64: found DPD v2 (Fgt) 0:GW_Xtreme_1:64: found Fortigate DPD 0:GW_Xtreme_1:64: found non-keepalive fortigate 0:GW_Xtreme_1:64: found NAT-T v3 0:GW_Xtreme_1:64: found NAT-T v0/1 0:GW_Xtreme_1:64: incoming proposal: 0:GW_Xtreme_1:64: proposal id = 1: 0:GW_Xtreme_1:64: protocol id = ISAKMP: 0:GW_Xtreme_1:64: trans_id = KEY_IKE. 0:GW_Xtreme_1:64: encapsulation = IKE/none 0:GW_Xtreme_1:64: type=oakley_encrypt_alg, val=3des_cbc. 0:GW_Xtreme_1:64: type=oakley_hash_alg, val=sha. 0:GW_Xtreme_1:64: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:64: type=oakley_group, val= :GW_Xtreme_1:64: trans_id = KEY_IKE. 0:GW_Xtreme_1:64: encapsulation = IKE/none 0:GW_Xtreme_1:64: type=oakley_encrypt_alg, val=3des_cbc. 0:GW_Xtreme_1:64: type=oakley_hash_alg, val=md5. 0:GW_Xtreme_1:64: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:64: type=oakley_group, val= :GW_Xtreme_1:64: my proposal 0:GW_Xtreme_1:64: proposal id = 1: 0:GW_Xtreme_1:64: protocol id = ISAKMP: 0:GW_Xtreme_1:64: trans_id = KEY_IKE. 0:GW_Xtreme_1:64: encapsulation = IKE/none 0:GW_Xtreme_1:64: type=oakley_encrypt_alg, val=aes_cbc. 0:GW_Xtreme_1:64: type=key_length, val=128. 0:GW_Xtreme_1:64: type=oakley_hash_alg, val=sha. 0:GW_Xtreme_1:64: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:64: type=oakley_group, val= :GW_Xtreme_1:64: negotiation failure 0:GW_Xtreme_1:64: negotiation error 0:GW_Xtreme_1:64: sending INFO message NO_PROPOSAL_CHOSEN to peer 0:GW_Xtreme_1:64: send IKE Packet(Info Mode): :500(if3) -> :500, len=40 0:GW_Xtreme_1:64: transmitted 40 bytes GW_Xtreme_1: Responder: parsed aggressive mode message #1 (ERROR) 0:GW_Xtreme_1:64: delete state 0:GW_Xtreme_1: has no ISAKMP SA, so delete 0:GW_Xtreme_1: deleting 0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1: deleted What is happening here?

80 Troubleshooting IPSEC tunnels What might be happening here? 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x86910FD30A4B2D02 R_COOKIE=0x len=460 0:GW_Xtreme_1: new connection. 0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID 0:GW_Xtreme_1:306: responder: aggressive mode get 1st message... 0:GW_Xtreme_1:306: parse all vendor ids... 0:GW_Xtreme_1:306: found DPD v2 0:GW_Xtreme_1:306: found DPD v2 (Fgt) 0:GW_Xtreme_1:306: found Fortigate DPD 0:GW_Xtreme_1:306: found non-keepalive fortigate 0:GW_Xtreme_1:306: found NAT-T v3 0:GW_Xtreme_1:306: found NAT-T v0/1 0:GW_Xtreme_1:306: negotiation result 0:GW_Xtreme_1:306: proposal id = 1: 0:GW_Xtreme_1:306: protocol id = ISAKMP: 0:GW_Xtreme_1:306: trans_id = KEY_IKE. 0:GW_Xtreme_1:306: encapsulation = IKE/none 0:GW_Xtreme_1:306: type=oakley_encrypt_alg, val=3des_cbc. 0:GW_Xtreme_1:306: type=oakley_hash_alg, val=sha. 0:GW_Xtreme_1:306: type=auth_method, val=preshared_key. 0:GW_Xtreme_1:306: type=oakley_group, val= :GW_Xtreme_1:306: phase1 lifetimes= :GW_Xtreme_1:306: sending DPD VID payloads... 0:GW_Xtreme_1:306: sending FGT DPD VID payloads... 0:GW_Xtreme_1:306: Sending VID payload... 0:GW_Xtreme_1:306: sending NATT VID payload (draft3)... 0:GW_Xtreme_1: put connection to natt list...ip= GW_Xtreme_1: Responder: sent aggressive mode message #1 (OK) 0:GW_Xtreme_1:306: send IKE Packet(STF_REPLY): :500(if3) -> :500, len=480 0:GW_Xtreme_1:306: retransmit timeout=6.

81 Troubleshooting IPSEC tunnels What might be happening here? 0: comes :500-> :500,ifindex=3... 0: Exchange=4 I_COOKIE=0x86910FD30A4B2D02 R_COOKIE=0x3B6D9F41F6D3307B len=132 0::306: received payloads HASH Notif 0:GW_Xtreme_1:306: responder: aggressive mode get 2nd response... 0:GW_Xtreme_1:306: using IPS_NAT_MODE_NONE. 0:GW_Xtreme_1:306: processing INITIAL-CONTACT 0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1:306: processed INITIAL-CONTACT 0:GW_Xtreme_1:306: set phase1 state timeout=28800 GW_Xtreme_1: Responder: parsed aggressive mode message #2 (DONE)

82 Troubleshooting IPSEC tunnels What might be happening here? 0: comes :500-> :500,ifindex=3... 0: Exchange=32 Message=0xE8E66D21 len=396 0: checking GW_Xtreme_ > :500 0:GW_Xtreme_1: phase1 found 0:GW_Xtreme_1:308: received payloads HASH SA NONCE KE ID ID 0:GW_Xtreme_1:308: responder received first quick-mode message 0:GW_Xtreme_1:309: peer proposal is: peer: / , me: / , ports=0/0, protocol=0/0 0:GW_Xtreme_1:309: trying tunel_xtreme_1 0:GW_Xtreme_1:309: specified selectors mismatch GW_Xtreme_1: - remote: type=7/7, ports=0/0, protocol=0/0 0:GW_Xtreme_1:309: local= , remote= :GW_Xtreme_1:309: - mine: type=7/7, ports=0/0, protocol=0/0 0:GW_Xtreme_1:309: local= , remote= :GW_Xtreme_1:308: sending INFO message INVALID_ID_INFORMATION to peer 0:GW_Xtreme_1:308: send IKE Packet(Info Mode): :500(if3) -> :500, len=68 0:GW_Xtreme_1:308: transmitted 68 bytes GW_Xtreme_1: Responder: parsed quick mode message #1 (ERROR) 0:GW_Xtreme_1:309: delete state