Transcript Dynamic VPN Scenario - V 1.0

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?
•
•
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
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
Types of VPNs
•
•
Remote Access VPN
Site-to-Site VPN


Connects multiple offices over
Internet
Reduces dependencies on frame
relay and leased lines
Branch
Office
Corporate
Site
Acme Corp
Site 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 1
Partner 2
Corporate
Site
Acme Corp
Site 2
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, HMACSHA-1, or others
• Digital Certificates,
Shared Secrets,Hybrid
Mode IKE
• Internet Key Exchange
(IKE), Public Key
Infrastructure (PKI)
All managed by security associations (SAs)
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
Encrypted Text
Clear Text
“The cow jumped
over the moon”
Encryption
Algorithm
“4hsd4e3mjvd3sd
a1d38esdf2w4d”
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
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
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:
Name: Bob
Organization: Fortinet
Public Key:
lk393l430fksffj398sdf1f594ier933d34w435d
CA: xxx.xxx.xxx.xxx
and more…
Basic IPSEC Implementation
An IPSec Session:
Putting It All Together
•
Bob attempts to connect to corporate email server
Certificate
Authority
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
Certificate
Authority
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
Certificate
Authority
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
Certificate
Authority
Deploying a VPN:
Questions to Ask
• Access control of VPN traffic
• Protecting remote access clients
• Providing Quality of Service (QoS) to VPN traffic
Different Types of VPN/Firewall
Topologies
Firewall
VPN
VPN
Firewall
VPN
VPN device is vulnerable to
attack eg. denial of service
Two connections to the
firewall for every
communication request
Bypasses security policy
Denial of service
Firewall
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
Certificate
Authority
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.
IPSEC FortiOS Implementation
• Example of Encapsulated packet.
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.
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.
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.
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.
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.
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?
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>
|- deloutbsa -- <name> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi> -- <spi>
|- dumpsa
+- stat -- flush
|- concentrator -- list
|- l2tp -- status
+- pptp -- status
(0)
(0)
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 vpn
concentrator 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.
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.
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
Diagnose commands for VPN
•
diag vpn gw list
The name of the GW, as the
FortiOS sees it. Note the Secuence
number
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
This•is the
rekey
This is the SPI cookie for
Diag
vpn time
gw flush
specified
on the all the GW (phase 1) negotiations on the FortiOS.
the specified GW. (For
 Flushes
phase 1 definition
• This is the most commons solutions of the “I changed theInformation
pre-shared keyonly)
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 vpn gw flush my_gw_1
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.
•
Forces a tunnel (phase 2) stop. It is the equivalent to the GUI down command
down
Shut down tunnel
dumpsa
dump all sa
•
Not recommended to use
•
This commands can force a “hard” cleanup of ALL the IPSEC tunnels up. It can be used to close only a named tunnel.
flush
flush tunnel SAs
list
reset
list all tunnel
flush tunnel SAs and reset NAT-T and DPD configuration
•
Not recommended to use
•
Not recommended to use
•
Forces a tunnel (phase 2) start. It is the equivalent to the GUI up command
stat
tunnel statistic info
up
Activate tunnel
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
Type of
tunnel
Bound
Interface?
IMPORTANT!
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=3
proxyid_num=1 child_num=0 refcnt=6 ilast=2 olast=2
These are the related GWs
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
DPD Detection status
proxyid=tunel_Xtreme_1 proto=0 sa=0 ref=1 auto_negotiate=0
src: 192.168.17.0/255.255.255.0(4):0
dst: 192.168.170.0/255.255.255.0(4):0
IPS
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
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 0
Received packets, rxp
-----------------------------------------------------name=GW_Xtreme_1 192.168.190.254:0->192.168.190.1:0
lgwy=dyn
Transmitted packets,
txp tun=tunnel mode=auto bound_if=3
proxyid_num=1 child_num=0 refcnt=7 ilast=0 olast=0
Received bytes, rxb
stat: rxp=26 txp=12 rxb=3104 txb=720
dpd: mode=active on=1 idle=5000ms retry=3Transmitted
count=0 seqno=1770
bytes, txb
natt:SA
mode=none
draft=0
interval=0
remote_port=0
status, 0 or 1
proxyid=tunel_Xtreme_1 proto=0 sa=1 ref=2 auto_negotiate=0
SA expire
src: 192.168.17.0/255.255.255.0(4):0
in second
MTU size
dst: 192.168.170.0/255.255.255.0(4):0
bytes soft=0 mtu=1436 expire=1743 replaywin=1024 seqno=3
SA: ref=3 options=0000000e in
type=00
life: type=01 bytes=0/0 timeout=1750/1800
dec: spi=f20ca131 esp=3des key=24 13a61bcf3d16ad918def5d197e25d155eb352eb3e8e385ea
ah=sha1 key=20 79ae86e3ccf1aeac8c53a193ef6603c580de5c1d
enc: spi=23487467 esp=3des key=24 209dec1ef5a70d893635ff99034ef31235494e5d883a459e
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
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.
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: 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
Local Network: 172.16.X.0/24
Host: 192.168.X1
Host: 172.16.X.1
FG: 192.168.X.254
FG: 172.16.X.254
A
B
“Routing network”
FortiGate A: 192.168.X0.1
FortiGate B: 192.168.X0.254
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 192.168.190.1
set psksecret ENC
DMBJa4L1j/g1sVDcUJOA5ljNyH3tKcRrLjzWrwYY8bNkZbNRu5djZR7gx/V1
XyKjNnfpQiChln5K+LzcwQ+KlsE/dlFjQLoLs8ZFC1jL9PEVF2we
next
end
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 192.168.17.0 255.255.255.0
set dst-subnet 192.168.170.0 255.255.255.0
next
end
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 192.168.190.254
set psksecret ENC
nKpdESzYM29H+XgMs5h+Js31zSguQwoY4KNE5pXVJE0J
cWiwCSB7+l7JZJ19hmKOdwBhqMzDY0pqMqsjxZY9B0xlRz
tM+ev+WlFqfiyMKahwDLj/
next
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 192.168.170.0 255.255.255.0
set dst-subnet 192.168.17.0 255.255.255.0
next
Diagnose commands for VPN
IPs of the related
0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0x0000000000000000
len=460
GWs, IF Index
0:GW_Xtreme_1: new connection.
0:GW_Xtreme_1:0: received payloads SA KE NONCE ID VID VID VID VID VID VID
Special payload
0:GW_Xtreme_1:16: responder: aggressive mode get 1st message...
IDs
Type of Encryption
0:GW_Xtreme_1:16: parse all vendor ids...
0:GW_Xtreme_1:16: found DPD v2
Dead Peer
0:GW_Xtreme_1:16: found DPD v2 (Fgt)
Detection?
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
Encryption negotiation:
Nat Transversal?
0:GW_Xtreme_1:16: found NAT-T v0/1
IKE. 3DES, SHA.
0:GW_Xtreme_1:16: negotiation result
0:GW_Xtreme_1:16: proposal id = 1:
Auth, Pre-shared Key.
0:GW_Xtreme_1:16: protocol id = ISAKMP:
Diffie Hellman Group, 5
0:GW_Xtreme_1:16:
trans_id = KEY_IKE.
0:GW_Xtreme_1:16:
encapsulation = IKE/none
(1536 Bytes)
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=1536.
0:GW_Xtreme_1:16: phase1 lifetimes=28800
0:GW_Xtreme_1:16: sending DPD VID payloads....
Type of Nat Transversal
0:GW_Xtreme_1:16:
sending
FGT
DPD
VID
payloads....
Send the
negotiation
0:GW_Xtreme_1:16:
Sending
VID
payload....
negotiation result
Aggressive mode
0:GW_Xtreme_1:16: sending NATT VID payload (draft3)....
packet,
outboud
0:GW_Xtreme_1: put connection to natt list...ip=192.168.190.1.
message #1 OK!
IF, retransmit
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=480
timeout
for an
0:GW_Xtreme_1:16: retransmit timeout=6.
answer
Diagnose commands for VPN
Received another packet
• This output from GW A on the VPN connection.
0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
Received second
0: Exchange=4 I_COOKIE=0x445BAAF5C4BA6AA6 R_COOKIE=0xE7167786D550F080
len=132 response
from the remote peer
0::16: received payloads 130 130 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
Started initial contact,
flushed state, initial
0:GW_Xtreme_1: flushed
contact OK.
0:GW_Xtreme_1:16: processed INITIAL-CONTACT
0:GW_Xtreme_1:16: set phase1 state timeout=28800
GW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode message #2 (DONE)
Aggressive mode (phase
1) message #2 OK.
Keylife in
seconds
Diagnose commands for VPN
• 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=84
0: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:500
An encrypted
0:GW_Xtreme_1: phase1 found
notification payload
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):192.168.190.254:500(if3) ->
192.168.190.1:500, len=84
A Dead Peer Detection RESPONSE
packet is sent over the phase 1
negotiation
Diagnose commands for VPN
The packets always
come from a remote
0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
peer to the central
•
Phase 2 negotiation on GW_A.
The available
GW is checked
0: Exchange=32 Message=0x9B2E4B90 len=396
0: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:500
Quick mode
0:GW_Xtreme_1: phase1 found
negotiation
0:GW_Xtreme_1:16: received payloads HASH SA NONCE KE ID ID
(phase 2)
0:GW_Xtreme_1:16: responder received first quick-mode message
0: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/0
0:GW_Xtreme_1:17:
trying tunel_Xtreme_1
The policy
is
Here the peers exchange their respective
0:GW_Xtreme_1:17: matched phase2 tunel_Xtreme_1
matched
to
a
encryption domains.
0:GW_Xtreme_1:17: autokey tunel_Xtreme_1
given 0:GW_Xtreme_1:17:
phase 2
Peer proposal is the remote GWs proposal, “me” is
negotiation result
what the local FG is expecting as Encryption
0:GW_Xtreme_1:17: proposal id = 1:
domain
0:GW_Xtreme_1:17: protocol id = IPSEC_ESP:
0:GW_Xtreme_1:17:
trans_id = ESP_3DES.
Encryption selection:
0:GW_Xtreme_1:17:
encapsulation = ENCAPSULATION_MODE_TUNNEL
0:GW_Xtreme_1:17:
type=AUTH_ALG, val=SHA1.
ESP: 3DES, Auth: SHA-1.
Tunnel0:GW_Xtreme_1:17:
mode,
set pfs=1536
Tunnel mode VPN
PFS, group
5
0:GW_Xtreme_1:17:
using tunnel mode.
0:GW_Xtreme_1:17: responder quick-mode set pfs=1536.
Phase 2 message #1 OK.
0:GW_Xtreme_1:17: quick-mode IDci type=4, len=8, chunk=c0a8aa00ffffff00
quick-mode IDcr type=4, len=8, chunk=c0a81100ffffff00
IKE reply0:GW_Xtreme_1:17:
to peer
GW_Xtreme_1:
Responder:
sent 192.168.190.1 quick mode message #1 (OK)
for phase 2,
0:GW_Xtreme_1:17:
send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=356
message
1.
0:GW_Xtreme_1:17:
retransmit timeout=6.
Retransmit
timeout.
Diagnose commands for VPN
•
Matched a phase 1, go to
next step
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=52 Replay protection
0: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1:500
status
0:GW_Xtreme_1: phase1 found
0:GW_Xtreme_1:17: received payloads HASH
Timers for
0:GW_Xtreme_1:17: replay protection enabled
the SA, soft
0:GW_Xtreme_1:17: set sa life soft seconds=1750.
and high
The 0:GW_Xtreme_1:17:
SA is now
set sa life hard seconds=1800.
0:GW_Xtreme_1:17: add SA #src=1 #dst=1
established
The Encryption domain
0:GW_Xtreme_1:17: src 0 7 192.168.17.0/192.168.17.255
is reconfirmed
0:GW_Xtreme_1:17: dst 0 7 192.168.170.0/192.168.170.255
0:GW_Xtreme_1:17:
installed SA: SPIs=f20ca133/23487469
The
SA is
The SNMP trap for
0:GW_Xtreme_1:17:
sending SNMP tunnel UP trap for tunel_Xtreme_1
installed
in the
0:GW_Xtreme_1:17: responder quick-mode done!
tunnel up is sent
kernel
GW_Xtreme_1: Responder: parsed 192.168.190.1 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
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=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)....
The Aggressive
mode message #1
0:GW_Xtreme:43: sending NATT VID payload (draft3
and draft1)....
is SENT by this unit. Look for the
0:GW_Xtreme:43: send IKE Packet(aggr_outI1):192.168.190.1:500(if3) ->
KEY word.
192.168.190.254:500, len=460
GW_Xtreme: Initiator: sent 192.168.190.254 aggressive mode message #1 (OK)
0:GW_Xtreme:43: retransmit timeout=6.
Diagnose commands for VPN
0: comes 192.168.190.254:500->192.168.190.1:500,ifindex=3....
0: Exchange=4 I_COOKIE=0x3D90E4DBCE3E4416 R_COOKIE=0x2BB0EBFC3FD1D28B len=480
0: checking GW_Xtreme 192.168.190.1 3 -> 192.168.190.254:500
0:GW_Xtreme: phase1 found
0:GW_Xtreme:43: received payloads SA KE NONCE ID VID VID VID VID VID 130 130 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
This is exactly the negotiation
0:GW_Xtreme:43:
type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
Information that was analyzed
0:GW_Xtreme:43:
type=OAKLEY_HASH_ALG, val=SHA.
0:GW_Xtreme:43:
type=AUTH_METHOD, val=PRESHARED_KEY.
On the central Gateway.
0:GW_Xtreme:43:
type=OAKLEY_GROUP, val=1536.
0:GW_Xtreme:43: phase1 lifetimes=28800
0:GW_Xtreme:43: negotiate success
Can you see differences?
0:GW_Xtreme:43: parse all vendor ids...
0:GW_Xtreme:43: found DPD v2
0:GW_Xtreme:43: found DPD v2 (Fgt)
If so, why?
0:GW_Xtreme:43: found Fortigate DPD
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 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
Diagnose commands for VPN
•
Key ITEMS:
What are the key elements of these messages:
o
Gateways IPs.
0:GW_Xtreme:tunel_Xtreme: IPsec SA connect 3 192.168.190.1>192.168.190.254:500, natt_mode=0
o PFS status
0:GW_Xtreme: using existing connection, dpd_fail=0
o Quick mode selectors
0:GW_Xtreme: found phase2 tunel_Xtreme
0:GW_Xtreme: IPsec SA connect 3 192.168.190.1 -> 192.168.190.254:500
negotiating
0: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/0
0:GW_Xtreme:44: send IKE Packet(quick_outI1):192.168.190.1:500(if3) ->
192.168.190.254:500, len=396
GW_Xtreme: Initiator: sent 192.168.190.254 quick mode message #1 (OK)
0:GW_Xtreme:44: retransmit timeout=6.
Diagnose commands for VPN
0: comes 192.168.190.254:500->192.168.190.1:500,ifindex=3....
0: Exchange=32 Message=0x6C777C6C len=356
0: checking GW_Xtreme 192.168.190.1 3 -> 192.168.190.254:500
0:GW_Xtreme: phase1 found
Identify key items
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=1775.
0:GW_Xtreme:44: set sa life hard seconds=1800.
0:GW_Xtreme:44: add SA #src=1 #dst=1
0:GW_Xtreme:44: src 0 4 192.168.170.0/255.255.255.0
0:GW_Xtreme:44: dst 0 4 192.168.17.0/255.255.255.0
0:GW_Xtreme:44: installed SA: SPIs=2348746a/f20ca134
0:GW_Xtreme:44: sending SNMP tunnel UP trap for tunel_Xtreme
GW_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
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=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:
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=1536.
0:Dialup_Xauth:30: phase1 lifetimes=28800
0: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=468
0: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=116
0::30: received payloads 130 130 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
Could you identify the differences
0:Dialup_Xauth: flushing
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 192.168.190.1 aggressive mode message #2 (DONE)
0:Dialup_Xauth: adding new dialup tunnel for 192.168.190.1:47407
0:Dialup_Xauth_0: added new dialup tunnel for 192.168.190.1:47407
0: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=68
Dialup_Xauth_0: Initiator: sent 192.168.190.1 xauth mode message #1 (OK)
0:Dialup_Xauth_0:31: retransmit timeout=6.
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=476
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0:Dialup_Xauth_0: phase1 found
What is the important
Information in this
Step of the negotiation?
0: comes 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....
0: Exchange=6 Message=0xCC9D3947 len=84
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0: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):192.168.190.254:4500(if3) -> 192.168.190.1:47407,
len=60
Dialup_Xauth_0: Initiator: sent 192.168.190.1 xauth mode message #2 (OK)
0:Dialup_Xauth_0:32: retransmit timeout=6.
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=476
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0: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:192.168.170.12, me:192.168.17.0/255.255.255.0, 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
Something interesting on this step?
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=1536.
0: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 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=348
0:Dialup_Xauth_0:33: retransmit timeout=6.
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=84
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0: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 192.168.190.1:47407->192.168.190.254:4500,ifindex=3....
0: Exchange=32 Message=0xC1A50450 len=476
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0:Dialup_Xauth_0: phase1 found
0: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=60
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0: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 192.168.190.1 xauth mode message #2 (DONE)
0:Dialup_Xauth_0:32: expire timeout=120.
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=52
0: checking Dialup_Xauth_0 192.168.190.254 3 -> 192.168.190.1:47407
0:Dialup_Xauth_0: phase1 found
0:Dialup_Xauth_0:33: received payloads HASH
Any special on this
0:Dialup_Xauth_0:33: replay protection enabled
negotiation step?
0:Dialup_Xauth_0:33: set sa life soft seconds=1788.
0:Dialup_Xauth_0:33: set sa life hard seconds=1800.
Which part of the IPSEC
0:Dialup_Xauth_0:33: add SA #src=1 #dst=1
0:Dialup_Xauth_0:33: src 0 7 192.168.17.0/192.168.17.255
negotation is?
0:Dialup_Xauth_0:33: dst 0 7 192.168.170.12/192.168.170.12
0:Dialup_Xauth_0:33: installed SA: SPIs=f20ca13c/1427bb6f
Something to note about
0:Dialup_Xauth_0:33: sending SNMP tunnel UP trap for Tunel_Xauth
it?
0:Dialup_Xauth_0:33: responder quick-mode done!
GOOD’old Phase2 end
phase of the negotiation!
Dialup_Xauth_0: Responder: parsed 192.168.190.1 quick mode message #2 (DONE)
0:Dialup_Xauth_0:33: expire timeout=120.
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 bytes
GW_Xtreme_1: Responder: parsed 192.168.190.1 quick mode message #1
(ERROR)
0:GW_Xtreme_1:42: delete state
Troubleshooting IPSEC Tunnels
••
Here
thethe
Phase
1phase
negotiation:
Hereiswith
Now
is
the
rest
of the
2 negotiation:
Phase 1 negotiation:
ChidoSL # 0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
0:
comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
0: Exchange=4
I_COOKIE=0x50A45C98F220D747 R_COOKIE=0x0000000000000000 len=460
0:
Exchange=32
Message=0x5A779BDD
len=396
0: checking
GW_Xtreme_1
192.168.190.254 3 -> 192.168.190.1:500
0:GW_Xtreme_1:
phase1
found
0: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1: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:
received payloads HASH SA NONCE KE ID ID
0:GW_Xtreme_1:41: parse all vendor ids...
0:GW_Xtreme_1:41:
received first quick-mode message
0:GW_Xtreme_1:41: foundresponder
DPD v2
0:GW_Xtreme_1:41: foundpeer
DPDproposal
v2 (Fgt) is: peer:192.168.170.0/255.255.255.0, me:192.168.17.0/255.255.255.0, ports=0/0,
0:GW_Xtreme_1:42:
0:GW_Xtreme_1:41:
protocol=0/0found Fortigate DPD
0:GW_Xtreme_1:41:
foundtrying
non-keepalive
fortigate
0:GW_Xtreme_1:42:
tunel_Xtreme_1
0:GW_Xtreme_1:41: found NAT-T v3
0:GW_Xtreme_1:42: matched phase2 tunel_Xtreme_1
0:GW_Xtreme_1:41: found NAT-T v0/1
0:GW_Xtreme_1:42:
autokey
tunel_Xtreme_1
0:GW_Xtreme_1:41: negotiation
result
0:GW_Xtreme_1:42:
negotiation
result
0:GW_Xtreme_1:41: proposal
id = 1:
0:GW_Xtreme_1:41:
protocol
id
=
ISAKMP:
0:GW_Xtreme_1:42: proposal id = 1:
0:GW_Xtreme_1:41:
trans_id = KEY_IKE.
0:GW_Xtreme_1:42: protocol id = IPSEC_ESP:
0:GW_Xtreme_1:41:
encapsulation = IKE/none
0:GW_Xtreme_1:42:
trans_id = ESP_3DES.
0:GW_Xtreme_1:41:
type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
0:GW_Xtreme_1:42:
encapsulation = ENCAPSULATION_MODE_TUNNEL
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:42:
type=AUTH_ALG, val=SHA1.
0:GW_Xtreme_1:41:
type=OAKLEY_GROUP,
val=1536.
0:GW_Xtreme_1:42: set pfs=1536
0:GW_Xtreme_1:41: phase1 lifetimes=28800
0:GW_Xtreme_1:42: using tunnel mode.
0:GW_Xtreme_1:41: sending DPD VID payloads....
0:GW_Xtreme_1:42:
negotiation
0:GW_Xtreme_1:41: sending
FGT DPD error
VID payloads....
0:GW_Xtreme_1:41:
sending
INFO message NO_PROPOSAL_CHOSEN to peer
0:GW_Xtreme_1:41: Sending
VID payload....
0:GW_Xtreme_1:41:
sending
NATT
VID
payload (draft3)....
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: put connection to natt list...ip=192.168.190.1.
0:GW_Xtreme_1:41: transmitted 68 bytes
GW_Xtreme_1: Responder: sent 192.168.190.1 aggressive mode message #1 (OK)
GW_Xtreme_1:
Responder: parsed 192.168.190.1 quick mode message #1 (ERROR)
0:GW_Xtreme_1:41: send IKE Packet(STF_REPLY):192.168.190.254:500(if3) -> 192.168.190.1:500, len=480
0:GW_Xtreme_1:42:
delete
state
0:GW_Xtreme_1:41: retransmit
timeout=6.
0:• comes
What192.168.190.1:500->192.168.190.254:500,ifindex=3....
would be your immediate next step?
0: Exchange=4 I_COOKIE=0x50A45C98F220D747
R_COOKIE=0xF4D31A5BF23A3E1E len=132
• What would you require to troubleshoot?
0::41: received payloads 130 130 HASH Notif
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:41: ignored duplicated INITIAL-CONTACT.
0:GW_Xtreme_1:41: set phase1 state timeout=28800
GW_Xtreme_1: Responder: parsed 192.168.190.1 aggressive mode
message #2 (DONE)
Any idea on which step
the error is?
Where?
Troubleshooting IPSEC Tunnels
0: comes 192.168.190.1:500->192.168.190.254:500,ifindex=3....
0: Exchange=4 I_COOKIE=0x6934F521FC030899
R_COOKIE=0x0000000000000000 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=1536.
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=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 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=1536.
0: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):192.168.190.254:500(if3) -> 192.168.190.1:500, len=40
0:GW_Xtreme_1:64: transmitted 40 bytes
GW_Xtreme_1: Responder: parsed 192.168.190.1 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?
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=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=1536.
0:GW_Xtreme_1:306: phase1 lifetimes=28800
0: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=480
0: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=132
0::306: received payloads 130 130 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 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=396
0: checking GW_Xtreme_1 192.168.190.254 3 -> 192.168.190.1: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:192.168.170.0/255.255.255.0,
me:192.168.17.0/255.255.255.0, 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=192.168.17.0-192.168.17.255, remote=192.168.170.0192.168.170.255
0:GW_Xtreme_1:309: - mine: type=7/7, ports=0/0, protocol=0/0
0:GW_Xtreme_1:309: local=192.168.17.0-192.168.17.127, remote=192.168.170.0192.168.170.255
0:GW_Xtreme_1:308: sending INFO message INVALID_ID_INFORMATION to peer
0:GW_Xtreme_1:308: send IKE Packet(Info Mode):192.168.190.254:500(if3) ->
192.168.190.1:500, len=68
0:GW_Xtreme_1:308: transmitted 68 bytes
GW_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 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: 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: 172.16.X+30.0/24
Ext IP:
192.168.X10.0/24
LAN: 192.168.X2.0/24
CHKP
FG LAN: 10.0.250.254
Backbone Net: 10.0.0.0/16
LAN: 172.16.X+30.0/24
PIX
LAN: 172.16.X+30.0/24
LAN:
192.168.XN.0/24
Ext IP:
192.168.XN0.0/24
SonicWall
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.
Corporate
Server Farm
Frame
Relay
•This is a typical
Network Topology
Customer
DMZ
ISP
Router
Local LAN
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 preferred
default 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:
•A Corporate Network, one or more WAN and
some MAN and other Networks below them
DMZ
WAN
Corporate LAN
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).
“Autonomous
System”
DMZ
WAN
Corporate LAN
Basic Routing Concepts
• There are two types of Autonomous Systems.
 Interior
• An Interior Autonomous System is usually the routing environment
within an organization, this organization might be a company, an
educational 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.
Basic Routing Concepts
•
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.
Basic Routing Concepts
• 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!
Basic Routing Concepts
• 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 router
device, 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.
How does OSPF works?
• 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?
• 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 overcomes
limitations 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 area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
Metric
S*
C
C
C
C
As we can see, there is
0.0.0.0/0 [20/0] via 200.38.193.226, ppp0
only one “Default GW”
10.10.170.0/24 is directly connected, dmz
so
ECMP
is
not
Priority
189.153.130.132/32
is directly connected, ppp0
192.168.170.0/24 is directly connected, internal enabled
200.38.193.226/32 is directly connected, ppp0
ECMP Example
••
These
are
the routes
withPRIORITY.
Now
The the
This
reason
is the
Fortigate
Kernel
is a
that
unit
Routing
we
have
arealooking
table
the
second
with
atofthe
the
GW
wrong
Static
with
route
table.
a different
with
This
aexample
priority:
DIFFERENT
has SAME
Priority.
Now
we
have
FG
with
couple
Default
GW
enabled:
 #static
That
evenlistthough we are looking at the kernel table information, we are not looking at the actual kernel routing
config
NETCHDT
router
diag ipis,route
table,
this
can be shown as:
tab=254
edit 0 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)
NETCHDT
#
get
router
info routing-table all
NETCHDT # diag ip route list
tab=254
set device
vf=0 scope=253
"wan1"
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
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)
Codes:
K -scope=253
kernel,
C - connected,
S - static, R - RIP, B - pref=10.10.170.1
BGP
This
is the
tab=254
set distance
vf=0
scope=253
20
type=1
proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/24
gwy=0.0.0.0
dev=4(dmz)
This is the NEW
tab=254
scope=253
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)
Ogateway
-vf=0
OSPF,
IA type=1
- OSPF
inter
area
tab=254
set
vf=0
scope=253
192.168.190.254
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)
Device ID or
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)
Priority
tab=254
set
priority
vf=0
scope=0
30
type=1 proto=11
prio=0type
0.0.0.0/0.0.0.0/0->0.0.0.0/0
pref=0.0.0.0
gwy=200.38.193.226
N1
- OSPF
NSSA
external
1, N2 - OSPF NSSA
external
type
2 dev=10(ppp0)
Index!
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
next
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)
E1vf=0
- OSPF
type
1, E2
- OSPF externalpref=0.0.0.0
type 2
tab=254
scope=0 external
type=1 proto=11
prio=0
0.0.0.0/0.0.0.0/0->0.0.0.0/0
end
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)
gwy=200.38.193.226
flag=00level-1,
hops=0 oif=10(ppp0)
i - vf=0
IS-IS,
L1 - IS-IS
L20.0.0.0/0.0.0.0/0->192.168.170.0/32
- IS-IS level-2, ia - IS-ISpref=192.168.170.1
inter area gwy=0.0.0.0 dev=5(internal)
tab=255
scope=253
type=3
proto=2
prio=0
And
the
routing
table
now
looks
like:
gwy=192.168.190.254
flag=00
hops=0
oif=3(wan1)
* - vf=0
candidate
tab=255
scope=253 default
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)
NETCHDT
# get
router infotype=3
routing-table
tab=255 vf=0
scope=253
proto=2allprio=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=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)
Codes:
K
kernel,
C
connected,
S
- static,prio=0
R - RIP,
B - BGP
tab=255 vf=0 scope=253 type=3 proto=2
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=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)
O
OSPF,
IA
OSPF
inter
area
S*
0.0.0.0/0
[20/0]
via
192.168.190.254,
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.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->189.153.130.132/32 pref=189.153.130.132 gwy=0.0.0.0 dev=10(ppp0)
N1 - OSPF
NSSA external
type
1,200.38.193.226,
N2 -prio=0
OSPF0.0.0.0/0.0.0.0/0->192.168.170.1/32
NSSA external
type 2
tab=255
vf=0 scope=254
type=2
proto=2
pref=192.168.170.1 gwy=0.0.0.0 dev=5(internal)
[20/0]
via
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)
E1
OSPF
external
type
1,
E2
OSPF
external
type
2
vf=0 scope=254 type=2isproto=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)
Ctab=255
directly
connected,
dmz
tab=25510.10.170.0/24
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)
i
IS-IS,
L1
IS-IS
level-1,
L2
IS-IS
level-2,
ia
IS-IS
inter
area
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)
vf=0 scope=253 type=3 proto=2
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)
Ctab=255
189.153.130.132/32
isprio=0
directly
connected, ppp0
* - candidate
default type=3 proto=2
tab=255
vf=0 scope=253
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=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)
Ctab=255
192.168.170.0/24
is directly
connected, internal pref=10.10.170.1 gwy=0.0.0.0 dev=4(dmz)
vf=0 scope=253 type=3 proto=2
prio=0 0.0.0.0/0.0.0.0/0->10.10.170.0/32
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)
S*
0.0.0.0/0
[20/0]
via
192.168.190.254,
wan1
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)
Ctab=255
is directly
connected, wan1 pref=127.0.0.1
tab=255192.168.190.0/24
vf=0 scope=254 type=2 proto=2
prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32
gwy=0.0.0.0 dev=7(root)
[20/0]
via
200.38.193.226,
ppp0
tab=255200.38.193.226/32
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)
C
is
directly
connected,
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.255/32
pref=192.168.190.1 gwy=0.0.0.0 dev=3(wan1)
Ctab=255
10.10.170.0/24
is directly
connected,
dmz 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)
vf=0 scope=253
type=3
proto=2 prio=0
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)
Ctab=255
189.153.130.132/32
is
directly
connected,
vf=0 scope=254 type=2 proto=2 prio=0ppp0
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)
Ctab=255
192.168.170.0/24
is
directly
connected,
internal
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)
Ctab=255
192.168.190.0/24
is directly
wan1
vf=0 scope=254
type=2 connected,
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)
C
200.38.193.226/32 is directly connected, ppp0
different priority and
hence, ECMP disabled
This is the priority
Same Metric
Now we have a couple of DGW
This is how
with ECMP
same routes
priority and same
enabled
look
like
metric, ECMP is now enabled.
Same Priority
Take a look on how the static
What! The routes looks
DGW are shown
exactly the SAME!
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 to
load 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.
About Policy Routing
• 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
» End
priority of learned routes
• This is new for FortiOS 3.0.
 This way you can select which is the preferred default GW of the
FortiOS.
 If anything fails, the Index of the Interface is used.
About Policy Routing
•
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