In this post we will
focus on
GRE over IPSec
IPSec over GRE
GRE over IPSec falls
under the category of Route-based VPNs.
The following are the
limitations with the policy based VPNs
- Does not support multicast or non IP traffic.
- The interesting traffic must be defined through an
ACL--increases the configuration complexity and maintenance.
GRE Over IPSec (IPSEC is transport):
It’s basically,
L2 Header
|
ESP
|
GRE
|
IP
|
Data
|
When doing GRE over IPsec, what really changes
comparing with normal IPsec encryption is WHAT MUST BE ENCRYPTED.
The decision of how traffic is encrypted or not depends on the
routing protocols.
If ospf route points to a tunnel and the tunnel is running encryption,
that particular traffic is encrypted.
This is how the limitation with the policy based VPNs is overcome
and complex/frequent ACL changes are not required.
Configuration wise its
same as traditional way of setting an IPSec tunnel.
The way we define the
proxy acl changes.
In GRE over IPsec, proxy
ACL will be just the endpoints of the GRE tunnel,
'permit gre hostA host B' (or permit gre any any)
Here the crypto map is applied under the physical interface which
the GRE tunnel uses. So GRE encapsulation first and encryption second.
If we apply the crypto map to the gre interface, it becomes IPSec
over GRE where encryption happens first and encapsulation second.
Eg:
R1----------R2==============R3-----------R4
R2==R3 -->GRE over
IPSec tunnel.
R1,R4 are end host that
run tcp,ping applications.
Configuration Steps:
Create a GRE tunnel
between R2 and R3.
Create ISAKMP policy.
Create crypto map and
associate it with the physical interface that the tunnel will use.
R2(config)#ip access-list ext GRE
R2(config-ext-nacl)#permit gre any any
R2(config)#crypto map GRE_O_IPSEC 50 ipsec-isakmp
R2(config-crypto-map)#match address GRE
R2(config-crypto-map)#set peer 4.4.4.4
R2(config-crypto-map)#set transform-set 3DES_MD5
Transport mode is
negotiated only when the traffic is from one router to other router(i.e.
sourced locally to the other end point).
This is controlled by
the proxy ACL.
For traffic going
through the router-->Always Tunnel mode is negotiated irrespective of
configuration.
For traffic going to the
router-->As per the configuration in the crypto map tunnel or transport.
If the proxy on R2 is
configured as 'permit gre any any' -->ipsec mode will be tunnel irrespective
of crypto map config.
If the proxy acl on R2
is configured as 'permit gre host 10.2.2.2 host 10.4.4.4 ' and tunnel
mode transport in crypto map,ipsec
tunnel will comeup in
transport mode.
Because of GRE header
and esp header, the MTU gets reduced. So if traffic is sent with default
MTU,the routers at the tunnel ends have to do
Fragmentation resulting
in higher CPU usage.
So to avoid
fragmentation,set the mtu to lower values.
If the hosts dont run
PMTUD,set the MSS in tcp syn & syn ack packets.
On R2,R3:
int tunnel0
ip tcp adjust-mss 1400
For UDP, we need to do
on the end host.
On R1,R4:
ip tcp mss 1450-->This
is when the tcp session if from the router,affects bgp,msdp...
IPSec VTI:
Conceptually same as GRE
over IPSec but without the additional GRE header overhead
Static VTI àused for site to site
Dynamic VTI àused for remote access
GRE over IPSec
|
VTI
|
More overhead but
negligible(4 bytes)
We
use GRE over IPsec because crypto map cannot define an interface in the
routing table, so dynamic routing protocol couldn't run without the the
tunnel interface.
|
Saves 4 bytes of gre
overhead
With
IPsec VTI we have an interface in the routing table, this remove the need to
have an extra GRE IP header encapsulation.
|
Multiprotocol
encapsulation
Ipv4,ipv6,is-is,etc
|
Single protocol
Ipv4 only over ipv4
ipsec tunnel
Ipv6 only over ipv6
ipsec tunnel
|
Line protocol based on
route to destination
|
Line protocol status
is accurate based on the ipsec phase2 negotiation
|
R4(config)#int tun0
R4(config-if)#tunnel
mode gre ip
R4(config-if)#tunnel
protection ipsec profile PROFILE1
|
R4(config)#int tun0
R4(config-if)#tunnel
mode ipsec ipv4
R4(config-if)#tunnel
protection ipsec profile PROFILE1
|
the frame
is [Eth Header][IP Header][GRE][Data]
|
[Eth
Header][IP Header][ESP header][Data][ESP trailer]
|
Supports
both tunnel and transport modes
|
Supports
only tunnel mode
|
Df-bit is
not carried upto esp header,so applications cannot do path mtu discovery
|
In
VTI mode,df-bit is carried upto the esp header.
Applications
can do path MTU discovery and we need not configure ‘ip mtu’ under the tunnel
interface.
We
can still configure ‘ip tcp adjust-mss’ for applications that cant do path
mtu discovery.
|
Tunnel
and then encrypt
|
Encrypt
and then tunnel
|
VTI configuration:
Phase 1 is same as in
crypto map based tunnel.
For phase 2,
The tunnel defines who the
end point i.e. tunnel destination is
The tunnel already
defines the traffic i.e. ip any any
We just need to
configure how the traffic must be treated using ‘crypto ipsec profiles’.
An IPSec profile just
specifies the transform set to be used in protecting the data plane.
R2(config)#crypto ipsec profile PROFILE2
R2(ipsec-profile)#set transform-set 3DES_MD5
The profiles can be
applied to both GRE tunnel and IPSec VTI tunnel.
Some platforms may not
do hardware switching of GRE packets.
IPSec over DMVPN:
DMPN is p-t-m layer 3
overlay VPN.
Logical hub and spoke
topology, direct spoke-to-spoke traffic is supported.
DMVPN is an mgre routing
technique
Order of operations:
Crypto first
NHRP second
Routing third
So if crypto ipsec
tunnel configuration is wrong, dmvpn will not work.
Configuration is same as
in GRE over IPSec.
The
peer address to use in the ISAKMP Policy is the NBMA Address, this is important to
understand and not to confuse configuring the Tunnel Private address
(10.1.100.x in this case).
Crypto Process is the first thing to start, IF
IPSEC IS NOT COMPLETED TUNNELS WILL NOT GO UP.
show crypto
ipsec sa | i pkts|peer
show ip
traffic | i Frag|frag
IPSec over GRE :
It’s basically,
L2 Header
|
GRE
|
ESP
|
IP
|
Data
|
Apply the crypto map
under the tunnel interface
Proxy ACL has to match
end-end entities.
Encryption first and
then GRE tunnel encapsulation.
