GRE over IPSEC Tunnels:
o GRE over ipsec vs ipsec over gre
o gre over ESP transport vs tunnel mode
o IP MTU & TCP Adjust MSS
Why use GRE & IPSEC Together ?
o Crypto maps have no interface in routing table
o implies that dynamic IGP routing isn't supported
o Static routing is hard to scale
o BGP could be used , but complicated design
Simple solution, add a tunnel interface
o Run routing inside of the GRE Tunnel
o Encrypt the GRE tunnel inside of IPSEC
Where does the Crypto Map apply ?
o If Crypto map attached at physical interface
o GRE over IPSEC ( IPSEC is transport )
o GRE ECAP FIRST
o Encryption Second
o Proxy-ACL with single entry " permit gre host A host B"
If Crypto map attached at tunnel interface level
o IPSEC over GRE ( GRE is transport )
o Encryption First
o GRE Second
o Proxy ACL with end to end entries
o Bad Design
GRE over ESP Transport Vs Tunnel mode
o |original IP Header | TCP/UDP | data |
o |New IP Header | GRE IP Header | GRE | Original IP Header | TCP/UDP| Data|
Transport mode :
o|New IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|
Tunnel mode:
o|New IP Header||GRE IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|
GRE over IPSEC & Fragmentation Problem
o Overhead is negligible , why do we care ?
o Extra 20 bytes is only 1% overhead of 1500 byte MTU
o DF bit isn't copied between headers
o PMTUD is now broken
o Route must encrypt then fragment
o Throughput is now out the window
How do we fix it ?
o offload fragmentation to the end host
IP MTU & TCP Adjust MSS
o How do we offload fragmentation to host ?
o Lower IP MTU on GRE to account for ESP overhead
o Actual overhead varies based on crypto algorithm
o E.g AES uses 16 byts block
o Good rule of thumb is about 1400 bytes normal MTU
o Jumbo MTU rule of thumb about 9000 bytes
What if host does not implement PMTUD ?
o Edit their MSS in TCP SYN & SYN ACK
o TCP adjust MSS is IP MTU -- 20 bytes
o IP 20 bytes TCP
configuration example:
https://supportforums.cisco.com/document/16066/how-configure-gre-over-ipsec-tunnel-routers
++++++++++ IPSEC VIRTUAL TUNNEL INTERFACE (VTI) ++++++++++++
IPSEC Virtual Tunnel Interface (VTI )
o Tunnel interface with direct ipsec encapsulation conceptually similar with GRE, but
without additional GRE overhead.
Two VTI variations:
o Static VTI (SVTI)
used for site to site VPN
o Dynamic VTI (DVTI)
used for remote access VPN
GRE over IPSEC Vs IPSEC VTI
o More overhead o Less overhead
(Arguably negligible)
o Multi protocol encapsulation o Simple protocol encapsulation
(E.g IPv4 , IPv6, IS-IS etc) (IPv4 over IPv4 or IPv6 over IPv6)
o On demand VPN o Always on
usually triggered by IGP No interesting traffic needed
o Line protocol based on route to destination o Line protocol based on ipsec phase 2
IPSEC VTI Configuration
o Phase 1 steps are identical to crypto map based tunnel
o Phase 2 -- tunnel already defines the who : i.e tunnel destination
o Tunnel already defines the what : i.e ip any any
o How is the traffic treated ? : define by crypto ipsec profile
Crypto IPSEC Profiles:
o IPSEC profile is essentially a stripped down version of crypto map
o Contains only ipsec phase 2 negotiation parameters :
i.e ipsec transform set
o Does not contain peer address or proxy ACL
-- Peer is the tunnel destination
-- Proxy ACL is non configurable
-- Permit ip / gre any any
o IPSEC profile can apply to both GRE tunnel & IPSEC VTI tunnel
-- Tunnel MTU is automatically adjusted for ESP overhead
+++++++ FINAL CONFIG +++++++
Crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp transfrom-set ESP_AES_SHA esp-aes esp-sha-hmac
!
! mode transport
crypto ipsec profile VTI_PROFILE
set transform-set ESP_AES_SHA
!
interface tunnel 0
ip address 78.0.0.7/24
ip tcp adjust-mss 1398
ip ospf 1 area 0
tunnel source lo0
tunnel mode ipsec IPv4
tunnel destination 150.1.8.9
tunnel protection ipsec profile VTI_PROFILE
!
IPSEC VTI Configuration example:
http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html
++++++ DMVPN over IPSEC ++++++
DMVPN Review
o DMVPN is P2M Layer 3 overlay VPN
-- Logical hub & spoke topology
-- Direct spoke to spoke traffic is supported
o DMVPN uses a combination of ----
-- Multiprotocol GRE tunnels (mGRE)
-- Next Hop Resolution Protocol ( NHRP)
-- IPSEC Crypto Profiles
-- Routing
IPSEC over DMVPN
o DMVPN typically implies IPSEC but doesn't required it .
-- DMVPN on its own is an mGRE routing technique
-- Can be combined with IPSEC to encrypt GRE
o IPSEC over DMVPN is same logic as ipsec over GRE
o Configured as Crypto ipsec profile to tunnel
o Only difference is dynamic spoke to spoke tunnels
DMVPN order of operations
o Crypto First ( Phase 1 ----> Phase 2 )
o NHRP second
o Routing third
IPSEC DMVPN Phase 1/2/3
Spoke to hub tunnels are always nailed up
o True for all DMVPN phase
o Implies hub always has IPSEC SA for all spokes
o Spokes to Spokes tunnels are on demand
-- True for DMVPN phase 2/3
-- Implies ipsec SA is established on demand between spokes
Scaling ipsec over DMVPN
o AS DMVPN cloud grows , ipsec stat grows
-- Linear ipsec SA stat from hub to spoke , spoke to spoke scal is on demand
o Scaling ISAKMP Authentication
-- PSK is supported but hard to manage
-- Wildcard PSKs are bad idea
-- PKI is the preferred solution
o Scaling IPSEC SAs
-- DMVPN over GETVPN
Configuration example:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-dmvpn.html
------------------------------oooooooooooooooooooooo------------------------------
o GRE over ipsec vs ipsec over gre
o gre over ESP transport vs tunnel mode
o IP MTU & TCP Adjust MSS
Why use GRE & IPSEC Together ?
o Crypto maps have no interface in routing table
o implies that dynamic IGP routing isn't supported
o Static routing is hard to scale
o BGP could be used , but complicated design
Simple solution, add a tunnel interface
o Run routing inside of the GRE Tunnel
o Encrypt the GRE tunnel inside of IPSEC
Where does the Crypto Map apply ?
o If Crypto map attached at physical interface
o GRE over IPSEC ( IPSEC is transport )
o GRE ECAP FIRST
o Encryption Second
o Proxy-ACL with single entry " permit gre host A host B"
If Crypto map attached at tunnel interface level
o IPSEC over GRE ( GRE is transport )
o Encryption First
o GRE Second
o Proxy ACL with end to end entries
o Bad Design
GRE over ESP Transport Vs Tunnel mode
o |original IP Header | TCP/UDP | data |
o |New IP Header | GRE IP Header | GRE | Original IP Header | TCP/UDP| Data|
Transport mode :
o|New IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|
Tunnel mode:
o|New IP Header||GRE IP Header|ESP Header|GRE|Original IP Header|TCP/UDP|Data|ESP Trailer|ESP Authen|
GRE over IPSEC & Fragmentation Problem
o Overhead is negligible , why do we care ?
o Extra 20 bytes is only 1% overhead of 1500 byte MTU
o DF bit isn't copied between headers
o PMTUD is now broken
o Route must encrypt then fragment
o Throughput is now out the window
How do we fix it ?
o offload fragmentation to the end host
IP MTU & TCP Adjust MSS
o How do we offload fragmentation to host ?
o Lower IP MTU on GRE to account for ESP overhead
o Actual overhead varies based on crypto algorithm
o E.g AES uses 16 byts block
o Good rule of thumb is about 1400 bytes normal MTU
o Jumbo MTU rule of thumb about 9000 bytes
What if host does not implement PMTUD ?
o Edit their MSS in TCP SYN & SYN ACK
o TCP adjust MSS is IP MTU -- 20 bytes
o IP 20 bytes TCP
configuration example:
https://supportforums.cisco.com/document/16066/how-configure-gre-over-ipsec-tunnel-routers
++++++++++ IPSEC VIRTUAL TUNNEL INTERFACE (VTI) ++++++++++++
IPSEC Virtual Tunnel Interface (VTI )
o Tunnel interface with direct ipsec encapsulation conceptually similar with GRE, but
without additional GRE overhead.
Two VTI variations:
o Static VTI (SVTI)
used for site to site VPN
o Dynamic VTI (DVTI)
used for remote access VPN
GRE over IPSEC Vs IPSEC VTI
o More overhead o Less overhead
(Arguably negligible)
o Multi protocol encapsulation o Simple protocol encapsulation
(E.g IPv4 , IPv6, IS-IS etc) (IPv4 over IPv4 or IPv6 over IPv6)
o On demand VPN o Always on
usually triggered by IGP No interesting traffic needed
o Line protocol based on route to destination o Line protocol based on ipsec phase 2
IPSEC VTI Configuration
o Phase 1 steps are identical to crypto map based tunnel
o Phase 2 -- tunnel already defines the who : i.e tunnel destination
o Tunnel already defines the what : i.e ip any any
o How is the traffic treated ? : define by crypto ipsec profile
Crypto IPSEC Profiles:
o IPSEC profile is essentially a stripped down version of crypto map
o Contains only ipsec phase 2 negotiation parameters :
i.e ipsec transform set
o Does not contain peer address or proxy ACL
-- Peer is the tunnel destination
-- Proxy ACL is non configurable
-- Permit ip / gre any any
o IPSEC profile can apply to both GRE tunnel & IPSEC VTI tunnel
-- Tunnel MTU is automatically adjusted for ESP overhead
+++++++ FINAL CONFIG +++++++
Crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 5
crypto isakmp transfrom-set ESP_AES_SHA esp-aes esp-sha-hmac
!
! mode transport
crypto ipsec profile VTI_PROFILE
set transform-set ESP_AES_SHA
!
interface tunnel 0
ip address 78.0.0.7/24
ip tcp adjust-mss 1398
ip ospf 1 area 0
tunnel source lo0
tunnel mode ipsec IPv4
tunnel destination 150.1.8.9
tunnel protection ipsec profile VTI_PROFILE
!
IPSEC VTI Configuration example:
http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html
++++++ DMVPN over IPSEC ++++++
DMVPN Review
o DMVPN is P2M Layer 3 overlay VPN
-- Logical hub & spoke topology
-- Direct spoke to spoke traffic is supported
o DMVPN uses a combination of ----
-- Multiprotocol GRE tunnels (mGRE)
-- Next Hop Resolution Protocol ( NHRP)
-- IPSEC Crypto Profiles
-- Routing
IPSEC over DMVPN
o DMVPN typically implies IPSEC but doesn't required it .
-- DMVPN on its own is an mGRE routing technique
-- Can be combined with IPSEC to encrypt GRE
o IPSEC over DMVPN is same logic as ipsec over GRE
o Configured as Crypto ipsec profile to tunnel
o Only difference is dynamic spoke to spoke tunnels
DMVPN order of operations
o Crypto First ( Phase 1 ----> Phase 2 )
o NHRP second
o Routing third
IPSEC DMVPN Phase 1/2/3
Spoke to hub tunnels are always nailed up
o True for all DMVPN phase
o Implies hub always has IPSEC SA for all spokes
o Spokes to Spokes tunnels are on demand
-- True for DMVPN phase 2/3
-- Implies ipsec SA is established on demand between spokes
Scaling ipsec over DMVPN
o AS DMVPN cloud grows , ipsec stat grows
-- Linear ipsec SA stat from hub to spoke , spoke to spoke scal is on demand
o Scaling ISAKMP Authentication
-- PSK is supported but hard to manage
-- Wildcard PSKs are bad idea
-- PKI is the preferred solution
o Scaling IPSEC SAs
-- DMVPN over GETVPN
Configuration example:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-dmvpn.html
------------------------------oooooooooooooooooooooo------------------------------
Thanks you very much for sharing these links. Will definitely check this out..
ReplyDeletebest wireless vpn router for small business