Concepts, Interoperability and Diagnose of VPN. – …pub.kb.fortinet.com/ksmcontent/Fortinet-TAC-Private/current/... · Concepts, Interoperability and Diagnose of VPN. ... the Fortigate

Concepts, Interoperability and Diagnose of VPN.– IPSEC / SSL –

– Routing Concepts –Xtream Team México, 2007.Cd. De México.

Agenda• IPSEC§ VPN Concepts§ Basic VPN Implementation.§ FortiOS IPSEC Implementation.§ Diagnose and Troubleshooting commands and its interpretation.

• Routing§ Dynamic Routing§ Static/Policy Routing

IPSEC VPN Concepts

What is a VPN?

• A VPN is a private connection over an open network

• A VPN includes authentication and encryption to protect data integrity and confidentiality

Acme Corp

Acme CorpSite 2 VPNVPN

Types of VPNs

• Remote Access VPN§ Provides access to internal

corporate network over the Internet§ Reduces long distance, modem

bank, and technical support costs

CorporateSite

Types of VPNs

• Remote Access VPN• Site-to-Site VPN

§ Connects multiple offices over Internet

§ Reduces dependencies on frame relay and leased lines

BranchOfficeCorporate

Site

Acme CorpSite 2

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 2Corporate

Site

Acme CorpSite 2

Partner 1

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

Why Use Virtual Private Networks?

• More flexibility• More scalability§ Add new sites, users quickly§ Scale bandwidth to meet demand

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

Components of a VPN

• Encryption• Message authentication• Entity authentication• Key management

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

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 (All managed by security associations (SAsSAs))

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

Encryption Explained

• Used to convert data to a secret code for transmission over an untrusted network

EncryptionAlgorithm

“The cow jumped over the moon”

“4hsd4e3mjvd3sda1d38esdf2w4d”

Clear TextClear Text Encrypted TextEncrypted Text

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 KeyShared Secret Key

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

Alice Public KeyAlice Public KeyEncryptEncrypt

Alice Private KeyAlice Private KeyDecryptDecrypt

BobBob AliceAlice

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

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

What is Key Management?

• A mechanism for distributing keys either manually or automatically

• Includes:§ Key generation§ Certification§ Distribution§ Revocation

Internet Key Exchange (IKE)

• Automates the exchange of security associations and keys between two VPN sites

• IKE provides:§ Automation and scalability§ Improved security

• Encryption keys be changed frequently• Hybrid IKE§ Proposed standard designed by Check Point§ Allows use of existing authentication methods

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:My Certificate:Name: Name: BobBobOrganization: Organization: FortinetFortinetPublic Key: Public Key: lk393l430fksffj398sdf1f594ier933d34w435dlk393l430fksffj398sdf1f594ier933d34w435dCA: CA: xxx.xxx.xxx.xxxxxx.xxx.xxx.xxxand moreand more……

Basic IPSEC Implementation

An IPSec Session: Putting It All Together• Bob attempts to connect to corporate email server

CertificateAuthority

An IPSec Session: Putting It All Together• Bob attempts to connect to corporate email 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 IPSec Session: Putting It All Together• Bob attempts to connect to corporate email 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


An IPSec Session: Putting It All Together• Bob attempts to connect to corporate email 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 email


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

VPN device is vulnerable to attack eg. denial of service

Two connections to the firewall for every communication request

Bypasses security policyDenial of service

VPN Firewall

VPN

Firewall

VPNFirewall

Different Types of VPN/Firewall Topologies

Only integrated VPN/firewall solutions can deliver full access control and consistent security policy enforcement


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

Attacker

Cable or xDSL

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.

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

FortiOS IPSEC Implementation

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

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.

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.

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.


• Example of Encapsulated packet.


• 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 packetwill 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.


• We stated that the traffic will be allowed if the policy permitsthe communication.§ This means the tunnel is established, and some packets arrive to

the Fortigate encrypted. The packets are decrypted and THEN theyare 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 canalso 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 islimited to the strictly required communication.


• 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.


• 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 andnow 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.

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.


• 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?

Diagnose and Troubleshooting commands and its interpretation.

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

Diagnose command for VPN

• The following commands are for VPN debugging only.§ Diag debug application ike <Integer> <IP!>

• Diag debug application ike 2 192.168.10.200

• The following is an example of usage and explanation of both diag debug/vpn branches for VPN.

Diagnose commands for VPN

• The diag vpn branch:NETCHDT # diag vpnconcentrator IPsec concentrator

• This is the branch to look on how are the concentrators working on the FG.

gw IPsec gateway• All the options for gateway (IPSEC phase 1) management.

ipsec general IPsec• Status of the IPSEC crypto devices.

l2tp vpn l2tp• The l2tp status output. DO NOT USE L2TP VPNs

pptp vpn pptp• The pptp status output. DO NOT USE PPTP VPNs

tunnel IPsec tunnel• All options for tunnel (IPSEC phase 2) management.


• Once the tunnel has been correctly configured, please be advisedof 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.


• 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 gwconfig 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

• diag vpn gw list

ChidoSL # GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:500 dpd-ok=1

state=5 connected=yes rekey-time=24991 cookies=33b6c25f59670972/b0b16fbb04b2ede8

state=4 connected=yes rekey-time=24961 cookies=2f50ab03532144e3/0b50051fb9d442e0

• Diag vpn gw flush§ Flushes all the GW (phase 1) negotiations on the FortiOS.

• This is the most commons solutions of the “I changed the pre-shared key 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 ipsecnegotiation 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 vpn gw flush my_gw_1

The name of the GW, as the FortiOS sees it. Note the Secuencenumber


This is the rekey time specified on the

phase 1 definition

This is the SPI cookie for the specified GW. (For

Information only)

Diagnose commands for VPN• ChidoSL # diag vpn tunnel

delinbsa remove tunnel sa• Not recommended to use

deloutbsa remove tunnel sa• Not recommended to use

dialup-list 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• Not recommended to use

flush 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 list all tunnelreset flush tunnel SAs and reset NAT-T and DPD configuration

• Not recommended to use

stat tunnel statistic info• Not recommended to use

up Activate tunnel• Forces a tunnel (phase 2) start. It is the equivalent to the GUI up command


• This is a tunnel that is correctly configured but unconnected:ChidoMX # diag vpn tunnel list list all ipsec tunnel in vd 0------------------------------------------------------name=GW_Xtreme_1 192.168.190.254:0->192.168.190.1:0 lgwy=dyn tun=tunnel mode=auto bound_if=3proxyid_num=1 child_num=0 refcnt=6 ilast=2 olast=2stat: rxp=21 txp=7 rxb=2544 txb=420dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=1236natt: mode=none draft=0 interval=0 remote_port=0proxyid=tunel_Xtreme_1 proto=0 sa=0 ref=1 auto_negotiate=0src: 192.168.17.0/255.255.255.0(4):0dst: 192.168.170.0/255.255.255.0(4):0

This is the phase 1 name

These are the related GWs IPS

Type of tunnel

Bound Interface?

IMPORTANT!

DPD Detection status

Nat Transversal Status

Proxy ID Identication, AKA: Encryption domain or phase 2

selection

These are the actual quick mode selectors or networks

that form the encryption domain


• This is correctly configured VPN tunnel but this time connected.ChidoSL # diag vpn tunnel listlist all ipsec tunnel in vd 0------------------------------------------------------name=GW_Xtreme_1 192.168.190.254:0->192.168.190.1:0 lgwy=dyn tun=tunnel mode=auto bound_if=3proxyid_num=1 child_num=0 refcnt=7 ilast=0 olast=0stat: rxp=26 txp=12 rxb=3104 txb=720dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=1770natt: mode=none draft=0 interval=0 remote_port=0proxyid=tunel_Xtreme_1 proto=0 sa=1 ref=2 auto_negotiate=0

src: 192.168.17.0/255.255.255.0(4):0dst: 192.168.170.0/255.255.255.0(4):0SA: ref=3 options=0000000e type=00 soft=0 mtu=1436 expire=1743 replaywin=1024 seqno=3life: type=01 bytes=0/0 timeout=1750/1800dec: spi=f20ca131 esp=3des key=24 13a61bcf3d16ad918def5d197e25d155eb352eb3e8e385ea

ah=sha1 key=20 79ae86e3ccf1aeac8c53a193ef6603c580de5c1denc: spi=23487467 esp=3des key=24 209dec1ef5a70d893635ff99034ef31235494e5d883a459e

ah=sha1 key=20 4cfc22406d65d0ec84355e8a5458a99655b17b42

Statistics:Received packets, rxpTransmitted packets, txp

Received bytes, rxbTransmitted bytes, txb

MTU size in bytes

SA expire in second

SA status, 0 or 1

Decryption keys, dec

Encription keys, enc

SPI encryption algorithm and AH hashing algorithm

Encryption key and hash, changes over time


• 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.

VPN Topology

• We are going to use the following topology conventions.

• Any of you should have two Fortigates, a couple per person or atleast 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: 192.168.X.0 would look like 192.168.1.0 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: 192.168.X0.0 would look like 192.168.10 where 1 was your assigned number plus the 0.

VPN Topology for local VPN tests

• The Network diagram for the local FG to FG VPN lab is:

Local Network: 192.168.X.0/24

Host: 192.168.X1

FG: 192.168.X.254

“Routing network”

FortiGate A: 192.168.X0.1

FortiGate B: 192.168.X0.254

A B

Local Network: 172.16.X.0/24

Host: 172.16.X.1

FG: 172.16.X.254


• 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 enableset nattraversal enableset proposal 3des-sha1 3des-md5set mode aggressiveset remote-gw 192.168.190.1set psksecret ENC

DMBJa4L1j/g1sVDcUJOA5ljNyH3tKcRrLjzWrwYY8bNkZbNRu5djZR7gx/V1XyKjNnfpQiChln5K+LzcwQ+KlsE/dlFjQLoLs8ZFC1jL9PEVF2we

nextend


• The phase 2 configuration of GW_A is:ChidoSL # show vpn ipsec phase2 config vpn ipsec phase2

edit "tunel_Xtreme_1"set pfs enableset phase1name "GW_Xtreme_1"set proposal 3des-sha1 3des-md5set replay enableset src-subnet 192.168.17.0 255.255.255.0set dst-subnet 192.168.170.0 255.255.255.0

nextend


• The Phase 1 configuration for GW_Bedit "GW_Xtreme"

set interface "wan1"set nattraversal enableset proposal 3des-sha1 3des-md5set mode aggressiveset remote-gw 192.168.190.254set psksecret ENC

nKpdESzYM29H+XgMs5h+Js31zSguQwoY4KNE5pXVJE0JcWiwCSB7+l7JZJ19hmKOdwBhqMzDY0pqMqsjxZY9B0xlRztM+ev+WlFqfiyMKahwDLj/next


• The phase 2 configuration for GW_B is:edit "tunel_Xtreme"

set pfs enableset phase1name "GW_Xtreme"set proposal 3des-sha1 3des-md5set replay enableset src-subnet 192.168.170.0 255.255.255.0set dst-subnet 192.168.17.0 255.255.255.0

next

Diagnose commands for VPN0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0x0000000000000000 len=4600:GW_Xtreme_1: new connection.0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID0: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 v20:GW_Xtreme_1:16: found DPD v2 (Fgt)0:GW_Xtreme_1:16: found Fortigate DPD0:GW_Xtreme_1:16: found non-keepalive fortigate0:GW_Xtreme_1:16: found NAT-T v30:GW_Xtreme_1:16: found NAT-T v0/10:GW_Xtreme_1:16: negotiation result0:GW_Xtreme_1:16: proposal id = 1:0:GW_Xtreme_1:16: protocol id = ISAKMP:0:GW_Xtreme_1:16: trans_id = KEY_IKE.0:GW_Xtreme_1:16: encapsulation = IKE/none0: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=1536.0:GW_Xtreme_1:16: phase1 lifetimes=288000:GW_Xtreme_1:16: sending DPD VID payloads....0:GW_Xtreme_1:16: sending FGT DPD VID payloads....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=192.168.190.1.GW_Xtreme_1: Responder: sent 192.168.190.1 aggressive mode message #1 (OK)0:GW_Xtreme_1:16: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=4800:GW_Xtreme_1:16: retransmit timeout=6.

IPs of the related GWs, IF Index

Special payload IDsType of Encryption

Dead Peer Detection?

Nat Transversal? Encryption negotiation:IKE. 3DES, SHA.Auth, Pre-shared Key.Diffie Hellman Group, 5 (1536 Bytes)

Type of Nat Transversal negotiation

Aggressive mode message #1 OK!

Send the negotiation result packet, outboud

IF, retransmit timeout for an

answer


• This output from GW A on the VPN connection.0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0xE7167786D550F080 len=132

0::16: received payloads 130 130 HASH Notif0: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-CONTACT0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1:16: processed INITIAL-CONTACT0:GW_Xtreme_1:16: set phase1 state timeout=28800GW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode message #2 (DONE)

Received another packet

Received second response from the remote peer

Started initial contact, flushed state, initial

contact OK.

Keylife in seconds

Aggressive mode (phase 1) message #2 OK.


• This is a typical Dead Peer Detection Packet after the initial contact.

0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=5 Message=0x8D78FB04 len=840: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:16: received payloads HASH Notif0:GW_Xtreme_1:16: received protected info0:GW_Xtreme_1:16: send IKE Packet(DPD response):192.168.190.254:500(if3) ->

192.168.190.1:500, len=84

An encrypted notification payload

A Dead Peer Detection RESPONSE packet is sent over the

phase 1 negotiation

Diagnose commands for VPN• Phase 2 negotiation on GW_A.0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=32 Message=0x9B2E4B90 len=3960: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:16: received payloads HASH SA NONCE KE ID ID0:GW_Xtreme_1:16: responder received first quick-mode message0:GW_Xtreme_1:17: peer proposal is: peer:192.168.170.0/255.255.255.0, me:192.168.17.0/255.255.255.0,

ports=0/0, protocol=0/00:GW_Xtreme_1:17: trying tunel_Xtreme_10:GW_Xtreme_1:17: matched phase2 tunel_Xtreme_10:GW_Xtreme_1:17: autokey tunel_Xtreme_10:GW_Xtreme_1:17: negotiation result0:GW_Xtreme_1:17: proposal id = 1:0:GW_Xtreme_1:17: protocol id = IPSEC_ESP:0:GW_Xtreme_1:17: trans_id = ESP_3DES.0:GW_Xtreme_1:17: encapsulation = ENCAPSULATION_MODE_TUNNEL0:GW_Xtreme_1:17: type=AUTH_ALG, val=SHA1.0:GW_Xtreme_1:17: set pfs=15360:GW_Xtreme_1:17: using tunnel mode.0:GW_Xtreme_1:17: responder quick-mode set pfs=1536.0:GW_Xtreme_1:17: quick-mode IDci type=4, len=8, chunk=c0a8aa00ffffff000:GW_Xtreme_1:17: quick-mode IDcr type=4, len=8, chunk=c0a81100ffffff00GW_Xtreme_1: Responder: sent 192.168.190.1 quick mode message #1 (OK)0:GW_Xtreme_1:17: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=3560:GW_Xtreme_1:17: retransmit timeout=6.

The packets always come from a remote peer to the central

The available GW is checked

Quick mode negotiation (phase 2)

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

The policy is matched to a given phase 2

Encryption selection:ESP: 3DES, Auth: SHA-1.

Tunnel mode VPNTunnel mode, PFS, group 5

Phase 2 message #1 OK.

IKE reply to peer for phase 2, message 1. Retransmit

timeout.

Diagnose commands for VPN• This is the second phase 2 message to the GW_A.0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=32 Message=0x9B2E4B90 len=520: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:17: received payloads HASH0:GW_Xtreme_1:17: replay protection enabled0:GW_Xtreme_1:17: set sa life soft seconds=1750.0:GW_Xtreme_1:17: set sa life hard seconds=1800.0:GW_Xtreme_1:17: add SA #src=1 #dst=10:GW_Xtreme_1:17: src 0 7 192.168.17.0/192.168.17.2550:GW_Xtreme_1:17: dst 0 7 192.168.170.0/192.168.170.2550:GW_Xtreme_1:17: installed SA: SPIs=f20ca133/234874690:GW_Xtreme_1:17: sending SNMP tunnel UP trap for tunel_Xtreme_10:GW_Xtreme_1:17: responder quick-mode done!

GW_Xtreme_1: Responder: parsed 192.168.190.1 quick mode message #2 (DONE)0:GW_Xtreme_1:17: expire timeout=120.

Matched a phase 1, go to next step

Replay protection status

Timers for the SA, soft

and highThe SA is now established The Encryption domain

is reconfirmedThe SA is

installed in the kernel

The SNMP trap for tunnel up is sent

The local FG unit has parsed the quick message #2 correctly. The tunnel as the FortiOS is concerned is now

created and fully operational


• This is from GW_B to the central GW_A.§ This time YOU will be doing the analysis.

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=1536.0: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 and draft1)....0:GW_Xtreme:43: send IKE Packet(aggr_outI1):192.168.190.1:500(if3) ->

192.168.190.254:500, len=460GW_Xtreme: Initiator: sent 192.168.190.254 aggressive mode message #1 (OK)0:GW_Xtreme:43: retransmit timeout=6.

The Aggressive mode message #1 is SENT by this unit. Look for the

KEY word.

This the KEY WORD. Why?

Diagnose commands for VPN0: comes 192.168.190.254:500->192.168.190.1:500,ifindex=3....0: Exchange=4 I_COOKIE=0x3D90E4DBCE3E4416 R_COOKIE=0x2BB0EBFC3FD1D28B len=4800: checking GW_Xtreme 192.168.190.1 3 -> 192.168.190.254:5000:GW_Xtreme: phase1 found0:GW_Xtreme:43: received payloads SA KE NONCE ID VID VID VID VID VID 130 130 HASH0:GW_Xtreme:43: initiator: aggressive mode get 1st response...0:GW_Xtreme:43: negotiation result0: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/none0: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=1536.0:GW_Xtreme:43: phase1 lifetimes=288000:GW_Xtreme:43: negotiate success0:GW_Xtreme:43: parse all vendor ids...0:GW_Xtreme:43: found DPD v20:GW_Xtreme:43: found DPD v2 (Fgt)0:GW_Xtreme:43: found Fortigate DPD0:GW_Xtreme:43: found non-keepalive fortigate0:GW_Xtreme:43: found NAT-T v30:GW_Xtreme:43: using IPS_NAT_MODE_NONE.0:GW_Xtreme:43: Sending initial contact0:GW_Xtreme:43: set phase1 state timeout=28800GW_Xtreme: Initiator: sent 192.168.190.254 aggressive mode message #2 (DONE)0:GW_Xtreme:43: send IKE Packet(STF_REPLY):192.168.190.1:500(if3) -> 192.168.190.254:500, len=132

This is exactly the negotiationInformation that was analyzed

On the central Gateway.

Can you see differences?

If so, why?


• What are the key elements of these messages:

0:GW_Xtreme:tunel_Xtreme: IPsec SA connect 3 192.168.190.1->192.168.190.254:500, natt_mode=0

0:GW_Xtreme: using existing connection, dpd_fail=00:GW_Xtreme: found phase2 tunel_Xtreme0:GW_Xtreme: IPsec SA connect 3 192.168.190.1 -> 192.168.190.254:500

negotiating0:GW_Xtreme:44: initiator quick-mode set pfs=1536...0:GW_Xtreme:44: try to negotiate with 1800 life seconds.0:GW_Xtreme:44: initiate an SA with selectors: 192.168.170.0/255.255.255.0-

>192.168.17.0/255.255.255.0, ports=0/0, protocol=0/00:GW_Xtreme:44: send IKE Packet(quick_outI1):192.168.190.1:500(if3) ->

192.168.190.254:500, len=396GW_Xtreme: Initiator: sent 192.168.190.254 quick mode message #1 (OK)0:GW_Xtreme:44: retransmit timeout=6.

Key ITEMS:

o Gateways IPs.

o PFS status

o Quick mode selectors

Diagnose commands for VPN0: comes 192.168.190.254:500->192.168.190.1:500,ifindex=3....0: Exchange=32 Message=0x6C777C6C len=3560: checking GW_Xtreme 192.168.190.1 3 -> 192.168.190.254:5000:GW_Xtreme: phase1 found0:GW_Xtreme:44: received payloads HASH SA NONCE KE ID ID0:GW_Xtreme:44: initiator quick-mode received first response0:GW_Xtreme:44: negotiation result0: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_TUNNEL0:GW_Xtreme:44: type=AUTH_ALG, val=SHA1.0:GW_Xtreme:44: using tunnel mode.0:GW_Xtreme:44: negotiate success0:GW_Xtreme:44: initiator install SA0:GW_Xtreme:44: replay protection enabled0:GW_Xtreme:44: set sa life soft seconds=1775.0:GW_Xtreme:44: set sa life hard seconds=1800.0:GW_Xtreme:44: add SA #src=1 #dst=10:GW_Xtreme:44: src 0 4 192.168.170.0/255.255.255.00:GW_Xtreme:44: dst 0 4 192.168.17.0/255.255.255.00:GW_Xtreme:44: installed SA: SPIs=2348746a/f20ca1340:GW_Xtreme:44: sending SNMP tunnel UP trap for tunel_XtremeGW_Xtreme: Initiator: sent 192.168.190.254 quick mode message #2 (DONE)0:GW_Xtreme:44: expire timeout=120.0:GW_Xtreme:44: send IKE Packet(STF_REPLY):192.168.190.1:500(if3) -> 192.168.190.254:500, len=52

Identify key items

Other VPN scenarios• What about an XAuth negotiation scenario?0: comes 192.168.190.1:47340->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x800B09EAE7EDBE45 R_COOKIE=0x0000000000000000 len=5120:Dialup_Xauth: new connection.0:Dialup_Xauth:0: received payloads SA KE NONCE ID VID VID VID VID VID0:Dialup_Xauth:30: responder: aggressive mode get 1st message...0:Dialup_Xauth:30: parse all vendor ids...0:Dialup_Xauth:30: found DPD v20:Dialup_Xauth:30: found DPD v2 (Fgt)0:Dialup_Xauth:30: found FortiClient v10:Dialup_Xauth:30: found NAT-T v30:Dialup_Xauth:30: found NAT-T v0/10:Dialup_Xauth:30: negotiation result0:Dialup_Xauth:30: proposal id = 1:0:Dialup_Xauth:30: protocol id = ISAKMP:0:Dialup_Xauth:30: trans_id = KEY_IKE.0:Dialup_Xauth:30: encapsulation = IKE/none0: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=1536.0:Dialup_Xauth:30: phase1 lifetimes=288000: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=192.168.190.1.Dialup_Xauth: Responder: sent 192.168.190.1 aggressive mode message #1 (OK)0:Dialup_Xauth:30: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:47340, len=4680:Dialup_Xauth:30: retransmit timeout=6.

Can you identify the differences on the IPSEC negotiation?

Other VPN Scenarios• Continuing with the XAuth Scenario.

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=4 I_COOKIE=0x800B09EAE7EDBE45 R_COOKIE=0xA1F94BDC8A9F401B len=1160::30: received payloads 130 130 HASH Notif0:Dialup_Xauth:30: responder: aggressive mode get 2nd response...0:Dialup_Xauth:30: using IPS_NAT_MODE_SILENT.0:Dialup_Xauth:30: processing INITIAL-CONTACT0:Dialup_Xauth: flushing 0:Dialup_Xauth: flushed 0:Dialup_Xauth:30: processed INITIAL-CONTACT0:Dialup_Xauth:30: set phase1 state timeout=28800Dialup_Xauth: Responder: parsed 192.168.190.1 aggressive mode message #2 (DONE)0:Dialup_Xauth: adding new dialup tunnel for 192.168.190.1:474070:Dialup_Xauth_0: added new dialup tunnel for 192.168.190.1:474070:Dialup_Xauth_0:30: initiating Xauth.0:Dialup_Xauth_0:31: send IKE Packet(xauth):192.168.190.254:4500(if3) -> 192.168.190.1:47407,

len=68Dialup_Xauth_0: Initiator: sent 192.168.190.1 xauth mode message #1 (OK)0:Dialup_Xauth_0:31: retransmit timeout=6.

Could you identify the differencesIn the IPSEC negotiation?

Other VPN Scenarios• Continuing with the XAuth Negotiation.0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=32 Message=0xC1A50450 len=4760: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=6 Message=0xCC9D3947 len=840: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:31: received payloads HASH PSEUDO_NATD0:Dialup_Xauth_0:31: XAUTH received 1st reply0:Dialup_Xauth_0:31: expire timeout=120.0:Dialup_Xauth_0: XAUTH authenticating user="test-mx" password="fortinet"0:Dialup_Xauth_0: xauth succeeded0:Dialup_Xauth_0:32: send IKE Packet(xauth):192.168.190.254:4500(if3) -> 192.168.190.1:47407,

len=60Dialup_Xauth_0: Initiator: sent 192.168.190.1 xauth mode message #2 (OK)0:Dialup_Xauth_0:32: retransmit timeout=6.

What is the importantInformation in this

Step of the negotiation?

Other VPN scenarios• The XAuth negotiation continues…

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=32 Message=0xC1A50450 len=4760: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:30: received payloads HASH SA NONCE KE ID ID0:Dialup_Xauth_0:30: responder received first quick-mode message0:Dialup_Xauth_0:33: peer proposal is: peer:192.168.170.12, me:192.168.17.0/255.255.255.0, ports=0/0,

protocol=0/00:Dialup_Xauth_0:33: trying Tunel_Xauth0:Dialup_Xauth_0:33: matched phase2 Tunel_Xauth0:Dialup_Xauth_0:33: dialup Tunel_Xauth0:Dialup_Xauth_0:33: negotiation result0: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_TUNNEL0:Dialup_Xauth_0:33: type=AUTH_ALG, val=MD5.0:Dialup_Xauth_0:33: set pfs=15360:Dialup_Xauth_0:33: using udp tunnel mode.0:Dialup_Xauth_0:33: responder quick-mode set pfs=1536.0:Dialup_Xauth_0:33: quick-mode IDci type=1, len=4, chunk=c0a8aa0c0:Dialup_Xauth_0:33: quick-mode IDcr type=4, len=8, chunk=c0a81100ffffff00Dialup_Xauth_0: Responder: sent 192.168.190.1 quick mode message #1 (OK)0:Dialup_Xauth_0:33: send IKE Packet(STF_REPLY):192.168.190.254:4500(if3) -> 192.168.190.1:47407,

len=3480:Dialup_Xauth_0:33: retransmit timeout=6.

Something interesting on this step??

Other VPN Scenarios• And it goes on… ;-)0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=5 Message=0x8E775B11 len=840: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:30: received payloads HASH Notif0:Dialup_Xauth_0:30: received protected info

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=32 Message=0xC1A50450 len=4760: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:33: Process retransmit....

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=6 Message=0xF49A9224 len=600: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:32: received payloads HASH PSEUDO_NATD0:Dialup_Xauth_0:32: XAUTH received 2nd replyDialup_Xauth_0: Initiator: parsed 192.168.190.1 xauth mode message #2 (DONE)0:Dialup_Xauth_0:32: expire timeout=120.

Something interesting on this slide?

Other VPN Scenarios

• At last, the end of this IPSEC negotiation ☺

0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....0: Exchange=32 Message=0xC1A50450 len=520: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:474070:Dialup_Xauth_0: phase1 found0:Dialup_Xauth_0:33: received payloads HASH0:Dialup_Xauth_0:33: replay protection enabled0:Dialup_Xauth_0:33: set sa life soft seconds=1788.0:Dialup_Xauth_0:33: set sa life hard seconds=1800.0:Dialup_Xauth_0:33: add SA #src=1 #dst=10:Dialup_Xauth_0:33: src 0 7 192.168.17.0/192.168.17.2550:Dialup_Xauth_0:33: dst 0 7 192.168.170.12/192.168.170.120:Dialup_Xauth_0:33: installed SA: SPIs=f20ca13c/1427bb6f0:Dialup_Xauth_0:33: sending SNMP tunnel UP trap for Tunel_Xauth0:Dialup_Xauth_0:33: responder quick-mode done!

Dialup_Xauth_0: Responder: parsed 192.168.190.1 quick mode message #2 (DONE)0:Dialup_Xauth_0:33: expire timeout=120.

Any special on this negotiation step?

Which part of the IPSEC negotation is?

Something to note about it?

GOOD’old Phase2 end phase of the negotiation!

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):192.168.190.254:500(if3) -> 192.168.190.1:500, len=68

0:GW_Xtreme_1:41: transmitted 68 bytesGW_Xtreme_1: Responder: parsed 192.168.190.1 quick mode message #1

(ERROR)0:GW_Xtreme_1:42: delete state

Troubleshooting IPSEC Tunnels

• What would be your immediate next step?

• What would you require to troubleshoot?

• Here is the Phase 1 negotiation:ChidoSL # 0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x50A45C98F220D747 R_COOKIE=0x0000000000000000 len=4600: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID0:GW_Xtreme_1:41: responder: aggressive mode get 1st message...0:GW_Xtreme_1:41: parse all vendor ids...0:GW_Xtreme_1:41: found DPD v20:GW_Xtreme_1:41: found DPD v2 (Fgt)0:GW_Xtreme_1:41: found Fortigate DPD0:GW_Xtreme_1:41: found non-keepalive fortigate0:GW_Xtreme_1:41: found NAT-T v30:GW_Xtreme_1:41: found NAT-T v0/10:GW_Xtreme_1:41: negotiation result0:GW_Xtreme_1:41: proposal id = 1:0:GW_Xtreme_1:41: protocol id = ISAKMP:0:GW_Xtreme_1:41: trans_id = KEY_IKE.0:GW_Xtreme_1:41: encapsulation = IKE/none0:GW_Xtreme_1:41: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.0:GW_Xtreme_1:41: type=OAKLEY_HASH_ALG, val=SHA.0:GW_Xtreme_1:41: type=AUTH_METHOD, val=PRESHARED_KEY.0:GW_Xtreme_1:41: type=OAKLEY_GROUP, val=1536.0:GW_Xtreme_1:41: phase1 lifetimes=288000:GW_Xtreme_1:41: sending DPD VID payloads....0:GW_Xtreme_1:41: sending FGT DPD VID payloads....0:GW_Xtreme_1:41: Sending VID payload....0:GW_Xtreme_1:41: sending NATT VID payload (draft3)....0:GW_Xtreme_1: put connection to natt list...ip=192.168.190.1.GW_Xtreme_1: Responder: sent 192.168.190.1 aggressive mode message #1 (OK)0:GW_Xtreme_1:41: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=4800:GW_Xtreme_1:41: retransmit timeout=6.

• Here is the rest of the Phase 1 negotiation:

0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x50A45C98F220D747

R_COOKIE=0xF4D31A5BF23A3E1E len=1320::41: received payloads 130 130 HASH Notif0:GW_Xtreme_1:41: responder: aggressive mode get 2nd response...0:GW_Xtreme_1:41: using IPS_NAT_MODE_NONE.0:GW_Xtreme_1:41: ignored duplicated INITIAL-CONTACT.0:GW_Xtreme_1:41: set phase1 state timeout=28800GW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode

message #2 (DONE)

• Now with the phase 2 negotiation:0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=32 Message=0x5A779BDD len=3960: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:41: received payloads HASH SA NONCE KE ID ID0:GW_Xtreme_1:41: responder received first quick-mode message0:GW_Xtreme_1:42: peer proposal is: peer:192.168.170.0/255.255.255.0, me:192.168.17.0/255.255.255.0, ports=0/0,

protocol=0/00:GW_Xtreme_1:42: trying tunel_Xtreme_10:GW_Xtreme_1:42: matched phase2 tunel_Xtreme_10:GW_Xtreme_1:42: autokey tunel_Xtreme_10:GW_Xtreme_1:42: negotiation result0:GW_Xtreme_1:42: proposal id = 1:0:GW_Xtreme_1:42: protocol id = IPSEC_ESP:0:GW_Xtreme_1:42: trans_id = ESP_3DES.0:GW_Xtreme_1:42: encapsulation = ENCAPSULATION_MODE_TUNNEL0:GW_Xtreme_1:42: type=AUTH_ALG, val=SHA1.0:GW_Xtreme_1:42: set pfs=15360:GW_Xtreme_1:42: using tunnel mode.0:GW_Xtreme_1:42: negotiation error0:GW_Xtreme_1:41: sending INFO message NO_PROPOSAL_CHOSEN to peer0:GW_Xtreme_1:41: send IKE Packet(Info Mode):192.168.190.254:500(if3) -> 192.168.190.1:500, len=680:GW_Xtreme_1:41: transmitted 68 bytesGW_Xtreme_1: Responder: parsed 192.168.190.1 quick mode message #1 (ERROR)0:GW_Xtreme_1:42: delete state

Any idea on which step the error is?

Where?

Troubleshooting IPSEC Tunnels0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x6934F521FC030899

R_COOKIE=0x0000000000000000 len=4600:GW_Xtreme_1: new connection.0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID

VID VID VID0: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 v20:GW_Xtreme_1:64: found DPD v2 (Fgt)0:GW_Xtreme_1:64: found Fortigate DPD0:GW_Xtreme_1:64: found non-keepalive fortigate0:GW_Xtreme_1:64: found NAT-T v30:GW_Xtreme_1:64: found NAT-T v0/10: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/none0: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=1536.0:GW_Xtreme_1:64: trans_id = KEY_IKE.0:GW_Xtreme_1:64: encapsulation = IKE/none0: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=1536.

0:GW_Xtreme_1:64: my proposal0: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/none0: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=1536.0:GW_Xtreme_1:64: negotiation failure0:GW_Xtreme_1:64: negotiation error0:GW_Xtreme_1:64: sending INFO message

NO_PROPOSAL_CHOSEN to peer0:GW_Xtreme_1:64: send IKE Packet(Info

Mode):192.168.190.254:500(if3) -> 192.168.190.1:500, len=400:GW_Xtreme_1:64: transmitted 40 bytesGW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode

message #1 (ERROR)0:GW_Xtreme_1:64: delete state0:GW_Xtreme_1: has no ISAKMP SA, so delete0:GW_Xtreme_1: deleting0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1: deleted

What is happening here?

0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x6934F521FC030899

R_COOKIE=0x0000000000000000 len=4600:GW_Xtreme_1: new connection.0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID

VID VID VID0: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 v20:GW_Xtreme_1:64: found DPD v2 (Fgt)0:GW_Xtreme_1:64: found Fortigate DPD0:GW_Xtreme_1:64: found non-keepalive fortigate0:GW_Xtreme_1:64: found NAT-T v30:GW_Xtreme_1:64: found NAT-T v0/10: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/none0: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=1536.0:GW_Xtreme_1:64: trans_id = KEY_IKE.0:GW_Xtreme_1:64: encapsulation = IKE/none0: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=1536.

Troubleshooting IPSEC tunnels• What might be happening here?0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x86910FD30A4B2D02 R_COOKIE=0x0000000000000000 len=4600:GW_Xtreme_1: new connection.0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID0: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 v20:GW_Xtreme_1:306: found DPD v2 (Fgt)0:GW_Xtreme_1:306: found Fortigate DPD0:GW_Xtreme_1:306: found non-keepalive fortigate0:GW_Xtreme_1:306: found NAT-T v30:GW_Xtreme_1:306: found NAT-T v0/10:GW_Xtreme_1:306: negotiation result0: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/none0: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=1536.0:GW_Xtreme_1:306: phase1 lifetimes=288000: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=192.168.190.1.GW_Xtreme_1: Responder: sent 192.168.190.1 aggressive mode message #1 (OK)0:GW_Xtreme_1:306: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=4800:GW_Xtreme_1:306: retransmit timeout=6.

Troubleshooting IPSEC tunnels

• What might be happening here?0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=4 I_COOKIE=0x86910FD30A4B2D02

R_COOKIE=0x3B6D9F41F6D3307B len=1320::306: received payloads 130 130 HASH Notif0: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-CONTACT0:GW_Xtreme_1: flushing 0:GW_Xtreme_1: flushed 0:GW_Xtreme_1:306: processed INITIAL-CONTACT0:GW_Xtreme_1:306: set phase1 state timeout=28800GW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode message

#2 (DONE)

Troubleshooting IPSEC tunnels• What might be happening here?

0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....0: Exchange=32 Message=0xE8E66D21 len=3960: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:5000:GW_Xtreme_1: phase1 found0:GW_Xtreme_1:308: received payloads HASH SA NONCE KE ID ID0:GW_Xtreme_1:308: responder received first quick-mode message0:GW_Xtreme_1:309: peer proposal is: peer:192.168.170.0/255.255.255.0,

me:192.168.17.0/255.255.255.0, ports=0/0, protocol=0/00:GW_Xtreme_1:309: trying tunel_Xtreme_10:GW_Xtreme_1:309: specified selectors mismatchGW_Xtreme_1: - remote: type=7/7, ports=0/0, protocol=0/00:GW_Xtreme_1:309: local=192.168.17.0-192.168.17.255, remote=192.168.170.0-

192.168.170.2550:GW_Xtreme_1:309: - mine: type=7/7, ports=0/0, protocol=0/00:GW_Xtreme_1:309: local=192.168.17.0-192.168.17.127, remote=192.168.170.0-

192.168.170.2550:GW_Xtreme_1:308: sending INFO message INVALID_ID_INFORMATION to peer0:GW_Xtreme_1:308: send IKE Packet(Info Mode):192.168.190.254:500(if3) ->

192.168.190.1:500, len=680:GW_Xtreme_1:308: transmitted 68 bytesGW_Xtreme_1: Responder: parsed 192.168.190.1 quick mode message #1 (ERROR)0:GW_Xtreme_1:309: delete state

VPN Topology

• We are going to use the following topology conventions.

• Any of you should have two Fortigates, a couple per person or atleast 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: 192.168.X.0 would look like 192.168.1.0 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: 192.168.X0.0 would look like 192.168.10 where 1 was your assigned number plus the 0.

Interoperability with VPN!

• This is the part where we work our way to get the VPNs are done.

• We are going to start a quick lab from here.

• We have today some other vendor’s units and we will use the debugging tools from above to make some interoperability tests.

VPN Topology for Interoperability

• This is the network topology.

LAN: 192.168.X1.0/24

LAN: 192.168.X2.0/24

LAN: 192.168.XN.0/24

LAN: 172.16.X+30.0/24

LAN: 172.16.X+30.0/24

LAN: 172.16.X+30.0/24

CHKP

PIX

SonicWall

FG LAN: 10.0.250.254

Backbone Net: 10.0.0.0/16

Ext IP: 192.168.X10.0/24

Ext IP: 192.168.XN0.0/24

Dynamic VPN Configuration.

Dynamic VPN Configuration.

• Please refer to the FortiOS 3.0 301 training course ;-)

§ Even it might look like we are joking, actually we are not. It’s the purpose of the FortiOS 301 training course to teach you exactly that. How to CONFIGURE a Dynamic VPN communication.

§ Be WE WILL explain you the CONCEPTS of routing that will help you with any implementation that you might encounter that might need an Dynamic Route scenario! ;-) ☺

Routing

Static Routing.

• The explanation of static routes is pretty straightforward, any network that you would like to reach must be connected to a router on a network that belongs to an interface on the Fortigate.

FrameRelay

CorporateServer Farm

ISP Router

Local LAN

CustomerDMZ

•This is a typical Network Topology

Policy Routing

• CRITICAL to configure policy Routing on the FortiOS.§ Check the index of the routes.

• Diag netlink interfase list

§ Check the metric of the Default Gateways.• The metric of ALL the Default GWs MUST be the SAME.• NEW For FortiOS 3.0 Policy Routing. The priority of the Default GW MUST BE

DIFFERENT.

§ The order of the Static Routes are important to define which is the preferreddefault Gateway.

§ The policy Routes MUST BE defined per Protocol.• Protocol 1 – ICMP• Protocol 6 – TCP• Protocol 17 – UDP• For other protocols numbers: http://www.iana.org/assignments/protocol-numbers

Dynamic Routing, OSPF

• OSPF is a intra Autonomous System routing Protocol.

• OSPF Stands for Open Shortest Path First.§ OSPF uses an algorithm that allows the detection of LINK-STATE

and unlimited hop count.§ It can detect the actual COST of a link, therefore it will decide the

best path to a destination even though the destination might be more hops away but over high speed Network connections.

Dynamic Routing Basic Concepts

Basic Routing Concepts.

The typical Corporate, MSSP or TELCO Network is as follows:

WAN

Corporate LAN

DMZWAN

MAN

•A Corporate Network, one or more WAN and some MAN and other Networks below them

Basic Routing Concepts

• In a network like this, to establish a static route scenario might be possible, but hard to maintain.

• In regard of routing in large organizations RIP have serious limitations as the number of hops is limited to 15 and it does not has link cost awareness.

• OSPF is the preferred routing protocol for these organizations as it can scale unlimited and has the ability to segment routing zones to reduce the routing traffic overhead.

Basic Routing Concepts• A Corporate Network Routing environment is usually known

as an “Autonomous System” (AS).

WAN

Corporate LAN

DMZWAN

MAN

“AutonomousSystem”


• There are two types of Autonomous Systems.§ Interior

• An Interior Autonomous System is usually the routing environmentwithin an organization, this organization might be a company, aneducational institution a Telco, etc. Any organization with a large Routing implementation using Dynamic Routing.

§ Exterior• An Exterior Autonomous System (AS) is usually the routing

environment that is OUTSIDE an organization, this exterior AS, could be competitor, a partner, a different university or simply, the internet.


• There are two types of Routing protocols that take ownership of the routing.

§ IGP. Interior Gateway Protocols. These IGP protocols are for routing inside and organization, no matter the type. This routing protocol is aware of the state of all the network and the probable route in case there is a need for link failover.

§ BGP. Exterior Gateway Protocol. These BGP protocols are in charge of letting the world know where a particular network resides. This way all the routers in the world know where to look for a specific network.

• The most common protocol for this is BGP, currently in its 4th version. The IANA has assigned a specific number to all the networks that are routable in the Internet. The BGP and the world keeps track of who owns which network by using the Autonomous System Number (ASN) as the identifier. Any ISP or organization that manages its own AS, has their own ASN.


• Interior VS Exterior GW Protocols.

• IGP Examples:§ OSPF, RIPv2

• EGP Examples:§ BGPv4

• BGP uses the ASN to keep track of all the link state, cost and destination of each network in the world.

• The Complete BGP table can be in the order of 140,000 Routes!


• Today, we will focus on the IGP OSPF as it’s the most common routing algorithm used on large organizations.§ There might be some organization that use BGP, but as we have

just explained this protocol is typically used by ISPs and companies with HUGE WANs so we must be sure that the customer is using this for a good reason and not an ISP arbitrary decision.

§ We talked about 140,000 routes. The FortiOS IS NOT a core routerdevice, so the FG can “talk” BGP, but only to participate on the BGP area, not to actually handle all the routing table and routing state decisions.

How does OSPF Work?

• OSPF is a protocol that calculates the cost of a path to a given destination.§ Based on this, the OSPF algorithm can calculate which is the best

option to reach that destination.

• OSPF Can detect if a link is down and based on the routing information it has, decide which is the best option to reroute the traffic.

• The cost is calculated based on the bandwitdh, using the formula:§ Cost = 108 / BW in bps.

• In this example, there are some 10Mbps Eth links and some other media. The Calculated Cost is shown.

How does OSPF works?

How does OSPF Works?

• The actual cost to a given network can be seen in the image shown:

• What is the cost to reach Network 192.213.11.0? And Network 222.211.10.0?

How OSPF works?

• Once the OSPF algorithm has the cost information to each of the given destination networks, OSPF starts creating the routing table.

• To make a more efficient way to broadcast information about routing, (which RIP does not do) the concept of an AREA is introduced.

OSPF Concepts.• Area.

§ An area is a “zone” where all the member routers/interfaces share routing information.

§ If a router connects to different areas, it’s usually called “Area Border Router” (ABR).

§ If a router is connected to different network using another routing protocol it is serving as a “Gateway” to the OSPF environment and so it’s called a ASBR.

§ Any router can be an ABR or ASBR.

§ The “Backbone” area is ALWAYS AREA 0.

OSPF Concepts

• What kind of links exist in OSPF?

§ Router Link.

§ Summary Link.

§ Network Link.

§ External Link.

OSPF Concepts

• What is Area 0?§ The area 0 Is the required area on any

OSPF scenario. It starts from the concept that there must be a “backbone” network that will help as the “bridge” between all the areas on the scenario. All the areas must have a way to access area 0 so they can propagate routing information to the whole AS accordingly.

§ There are some special scenarios that the Area 0 is unreachable using a direct link so there are Virtual Links to fulfill this limitation.

§ There are Intra-Area and Inter-Area routes, shown in the figure.

OSPF Concepts

• Neighbors.

§ A neighbor is a router that share the same segment. The neighbors must agree on the following:

• Area-id, authentication, hello and dead interval.

• Hello Intervals: OSPF exchanges Hello packets on each segment. This is a form of keep-alive used by routers in order to acknowledge their existence on a segment and in order to elect a designated router (DR) on multi-access segments. The Hello interval specifies the length of time, in seconds, between the hello packets that a router sends on an OSPF interface.

• Dead interval: is the number of seconds that a router's Hello packets have not been seen before its neighbors declare the OSPF router down. OSPF requires these intervals to be exactly the same between two neighbors.

OSPF Concepts

• Adjacency.

§ It’s the next step after neighbor negotiation. This is the process where all the routers in a given area learn about all the link information and state of all the links.

§ Once the adjacency process is finished, all the routers in the area have all the link and routing information for the specific area.

§ It is important to be careful when the customer has a Frame-Relay scenario as the DR or BDR must be selected with manual configuration of routes to the point to multipoint connection on the frame relay cloud.

OSPF Concepts

• Route summarization.§ Another of the advantages of OSPF, is the ability to summarize

route updates on a single route update. There are two types of route summarization:

• Inter-Area Summarization: This is the routing update of a whole area to other areas within the AS.

OSPF Concepts

• Route summarization.§ External Route Summarization: This is the routing update of areas

that are outside the AS. This option is only available on ASBR. That redistribute routes from a different network.

• It is important to note that overlapping network addresses can cause a problem with correct routing decision.

• Redistribution.§ Redistribution is the action of a router that receives routes using a

different protocol (i.e. BGP, RIP or static) and injects them to the OSPF community.

• OSPF allows VLSM (Variable Length Subnet Masks) so a set or routing networks can be updated sending a bigger network. This overcomeslimitations of RIP or IGRP.

OSPF Concepts

• Default GW Redistribution.§ OSPF allows for the distribution of a default GW on a ASBR, but

this must be defined manually on the router and it also has to have a Default GW itself.

• Mutual redistribution.§ When the scenario requires to distribute networks from a non

OSPF environment to the OSPF areas, it is very important to be careful not allowing a route injected from the outside, back to the outside. There is a need to use ACLS for these specific scenarios. This is a critical point to be aware of when dealing with OSPF environments.

HOW TO configure OSPF in FortiOS?

• Refer to the OSPF documentation on the FortiOS for more information.§ The 301 training course will actually have a very good example of

OSPF which will be very helpful once the mayor concepts are learn.

• Tips:§ OSPF uses Multicast to send routing updates, hello and link-state

negotiation tables. Refer to the documented OSPF multicast addresses for more information.

§ OSPF uses Area IDs and Router IDs in an “IP format” so, the actual IP of a Router can be the Area ID or the router ID, this is a coincidence to handle more easily the 32 bits of this field, which happens to be the same size as an IP.

Hints on Static Routing with FortiOS

• ECMP, Equal Cost Multi Path.§ The FortiOS 3.0, MR3 and high have a new functionality on the

static routing algorithms. This new functionality allows the FortiOS to do session-based round robin load balance among 2 or more Internet connections.

§ The requirements in order for this to work are:

• All the default GWs must have the same Metric/Distance and the SAME PRIORITY.

– The priority is a new concept on the FortiOS 3.0 routing. The priority specifies when to use a route from another with the same metric. If two or more routes have the same priorities and metric/distance, the sessions will be load balanced among these routes.

ECMP example.

• First we show the actual routing table of a FortiGate 3.0 unit:

NETCHDT # get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP

O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default

S* 0.0.0.0/0 [20/0] via 200.38.193.226, ppp0C 10.10.170.0/24 is directly connected, dmzC 189.153.130.132/32 is directly connected, ppp0C 192.168.170.0/24 is directly connected, internalC 200.38.193.226/32 is directly connected, ppp0

Metric

Priority

As we can see, there is only one “Default GW”so ECMP is not enabled

ECMP Example• Now we have a FG with a couple of Default GW enabled:

NETCHDT # get router info routing-table allCodes: K - kernel, C - connected, S - static, R - RIP, B - BGP

O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default

S* 0.0.0.0/0 [20/0] via 192.168.190.254, wan1[20/0] via 200.38.193.226, ppp0

C 10.10.170.0/24 is directly connected, dmzC 189.153.130.132/32 is directly connected, ppp0C 192.168.170.0/24 is directly connected, internalC 192.168.190.0/24 is directly connected, wan1C 200.38.193.226/32 is directly connected, ppp0

Same Metric

Same Priority

Now we have a couple of DGW with same priority and same metric, ECMP is now enabled. Take a look on how the static DGW are shown

• Now the Fortigate unit have the second GW with a different priority:config router static

edit 0set device "wan1"set distance 20

set gateway 192.168.190.254set priority 30

nextend

And the routing table now looks like:NETCHDT # get router info routing-table allCodes: K - kernel, C - connected, S - static, R - RIP, B - BGP

O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area* - candidate default

S* 0.0.0.0/0 [20/0] via 192.168.190.254, wan1

[20/0] via 200.38.193.226, ppp0C 10.10.170.0/24 is directly connected, dmzC 189.153.130.132/32 is directly connected, ppp0C 192.168.170.0/24 is directly connected, internalC 192.168.190.0/24 is directly connected, wan1C 200.38.193.226/32 is directly connected, ppp0

What! The routes looks exactly the SAME!

• The reason is that we are looking at the wrong table. This example has SAME PRIORITY.§ That is, even though we are looking at the kernel table information, we are not looking at the actual kernel routing

table, this can be shown as:NETCHDT # diag ip route list tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->200.38.193.226/32 pref=189.153.130.132 gwy=0.0.0.0 dev=10(ppp0)tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.0/24 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/24 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.0/24 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)

tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0gwy=200.38.193.226 flag=00 hops=0 oif=10(ppp0)gwy=192.168.190.254 flag=00 hops=0 oif=3(wan1)

tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.0/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.255/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)

tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.1/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.1/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->189.153.130.132/32 pref=189.153.130.132 gwy=0.0.0.0 dev=10(ppp0)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.0/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.255/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)

tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.1/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.255/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)

This is the priorityThis is the Device

ID or Index!

This is how ECMP routes enabled look like

• This is the Kernel Routing table with the Static route with a DIFFERENT Priority.NETCHDT # diag ip route list tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->200.38.193.226/32 pref=189.153.130.132 gwy=0.0.0.0 dev=10(ppp0)tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.0/24 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/24 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)

tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.0/24 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=200.38.193.226 dev=10(ppp0)tab=254 vf=0 scope=0 type=1 proto=11 prio=30 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=192.168.190.254 dev=3(wan1)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.0/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.255/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)

tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.1/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.1/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->189.153.130.132/32 pref=189.153.130.132 gwy=0.0.0.0 dev=10(ppp0)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.0/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.170.255/32 pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)

tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.1/32 pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.190.255/32 pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=7(root)

This is the NEW Priority

These are the routes with different priority and

hence, ECMP disabled

About Policy Routing

• As you can see, the ECMP really affects the way the policy routing used to function of FortiOS 2.8.§ Why? As we could see, the ECMP requirements are the same as

the previous Policy Routing implementation, this makes the FG toload balance the sessions per Internet connection. Making the policy routes definitions “unstable” or “unusable”.

• The only way to get the policy routing working again, you must define a HIGHER priority to the DGW route that IS NOT the desired preferred GW. After this the previous Policy routing explanation works exactly as expected.


• The policy routing is based on the following principles:§ There is always a “preferred” default GW on a FG unit.§ The routes that are learnt by the “Retrieve Default GW from server”

on the interface definition can be modified on its PRIORITY but ONLY VIA CLI:

• conf sys interface– Edit “INT”

» set priority priority of learned routes» End

• This is new for FortiOS 3.0.

§ This way you can select which is the preferred default GW of theFortiOS.

§ If anything fails, the Index of the Interface is used.


• Best practices for policy routing.§ The policy routes must be defined per protocol.

• Protocol 1 – ICMP.• Protocol 17 – UDP.• Protocol 6 – TCP.• Visit: http://www.iana.org/assignments/protocol-numbers for a complete listing of

all 255 supported protocols for IP.

§ We should only write the policy routes for the traffic that will no go through the preferred default GW.

§ The Policy Routes have preference over the static routes or any other routing protocol. It does not gets over the Distance or metric limitation, but if there are routes with the same distance the policy routes will always have preference.

§ The Fortigate is not routing the traffic as it should be?• Please check that the distance of the Default GW is higher than the other route

that is not being used.

Thanks!David Ramírez Joya, CISSP, FCNSP

Documents

Concepts, Interoperability and Diagnose of VPN. – …pub.kb.fortinet.com/ksmcontent/Fortinet-TAC-Private/current/... · Concepts, Interoperability and Diagnose of VPN. ... the Fortigate