Hairpin L2L IPSEC VPN - No GRE

Unanswered Question
Feb 11th, 2010

Greetings, we currently have a small hub and spoke deployement consisting of a single hub and four spoke sites, all running 12.4 Advanced Security on 877 ISR's, we would like to be able to communicate between spokes within establishing a fully meshed topology or by using GRE and dynamic routing as the routers dont have the feature set necessary to support it.


Hub - 192.168.10.0/24

Spoke A - 192.168.20.0/24

Spoke B- 192.168.30.0/24

Spoke C - 192.168.40.0/24

Spoke D - 192.168.50.0/24


L2L Tunnels have already been formed and all is working fine, i have also enabled reverse route on all connections which i thought would take care of the routing without having to add statics on all sites.


Any suggestions would be much appreciated.


Regards

Relevant Hub Config:

crypto isakmp key 85m4EhiH address 1.1.1.1 no-xauth
crypto isakmp key upXJ3R3j address 2.2.2.2 no-xauth
crypto isakmp key dZmpt9cp address 3.3.3.3 no-xauth
crypto isakmp key SGYXHKwa address 4.4.4.4 no-xauth

!

crypto ipsec transform-set 3DesL2L esp-3des

!

crypto map hqmap 1 ipsec-isakmp
description ****** Link to SpokeA ******
set peer 1.1.1.1
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 101
reverse-route
crypto map hqmap 2 ipsec-isakmp
description ****** Link to SpokeB ******
set peer 2.2.2.2
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 102
reverse-route
crypto map hqmap 3 ipsec-isakmp
description ****** Link to SpokeC ******
set peer 3.3.3.3
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 103
reverse-route
crypto map hqmap 4 ipsec-isakmp
description ****** Link to SpokeD ******
set peer 4.4.4.4
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 104
reverse-route
crypto map hqmap 65535 ipsec-isakmp dynamic clientmap

!

ip route 0.0.0.0 0.0.0.0 Dialer1

!

ip nat inside source route-map nonat interface Dialer1 overload

!

access-list 100 remark ****** NAT ACL ******
access-list 100 deny   ip 192.168.10.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 100 permit ip 192.168.10.0 0.0.0.255 any

!
access-list 101 remark ****** Link to SpokeA******
access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 102 remark ****** Link to SpokeB ******
access-list 102 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255
access-list 103 remark ****** Link to SpokeC ******
access-list 103 permit ip 192.168.10.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 104 remark ****** Link to SpokeD ******
access-list 104 permit ip 192.168.10.0 0.0.0.255 192.168.50.0 0.0.0.255

!

Show IP Route on Hub

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     81.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       81.112.49.0/24 is directly connected, Dialer1
C       81.113.20.1/32 is directly connected, Dialer1
C    192.168.10.0/24 is directly connected, Vlan1
S    192.168.20.0/24 [1/0] via 1.1.1.1
S    192.168.30.0/24 [1/0] via 2.2.2.2
S    192.168.40.0/24 [1/0] via 3.3.3.3
S    192.168.50.0/24 [1/0] via 4.4.4.4
S*   0.0.0.0/0 is directly connected, Dialer1

Show IP Route on Spoke

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     81.0.0.0/32 is subnetted, 1 subnets
C       81.10.88.1 is directly connected, Dialer1
C    212.6.112.0/24 is directly connected, Dialer1
C    192.168.20.0/24 is directly connected, Vlan1
S*   0.0.0.0/0 is directly connected, Dialer1
S    192.168.0.0/16 [1/0] via ***HUB IP ADDRESS**

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Thu, 02/11/2010 - 10:36

The routers that you have are perfectly fine,Multipoint GRE (DMVPN) is really the best solution even if only static routes, as once done you have full connectivity.

Mark Rigby Thu, 02/11/2010 - 10:40

These are 877 ISR's running Advanced Security, i did consider DMVPN but for simplicity sake and the fact that i dont have access to EIGRP/OSPF in the feature set i had hoped i could make do with just IPSEC, we are only talking about nominal ammounts of spoke to spoke traffic.


Regards

Paolo Bevilacqua Thu, 02/11/2010 - 12:06

Routing protocol is not mandatory. You can use static or RIPv2 that also works well.

What makes the difference, is the multipoint GRE will avoid a lot of convolute configuration, virtual interfaces, etc.

Mark Rigby Thu, 02/11/2010 - 14:01

This is the configuration i have so far, with this i can ping each spoke on both the LAN IP and Tunnel IP Address, i can also ping the Tunnel IP Address from a Spoke router.


However the spoke router cant ping another Spoke on the LAN IP Address or Tunnel Interface other than the one adjacent to it.

Hub Config


interface Tunnel0
ip address 10.255.255.1 255.255.255.252
tunnel source Dialer1
tunnel destination 1.1.1.1

ip mtu 1420
tunnel path-mtu-discovery

crypto map hqmap
!
interface Tunnel2
ip address 10.255.255.5 255.255.255.252
tunnel source Dialer1
tunnel destination 2.2.2.2
crypto map hqmap

ip mtu 1420
  tunnel path-mtu-discovery

!
interface Tunnel3
ip address 10.255.255.9 255.255.255.252
tunnel source Dialer1
tunnel destination 3.3.3.3
crypto map hqmap

ip mtu 1420
  tunnel path-mtu-discovery

!        
interface Tunnel4
ip address 10.255.255.13 255.255.255.252
tunnel source Dialer1
tunnel destination 4.4.4.4
crypto map hqmap

ip mtu 1420
  tunnel path-mtu-discovery

!

ip route 192.168.20.0 255.255.255.0 10.255.255.2
ip route 192.168.30.0 255.255.255.0 10.255.255.6
ip route 192.168.40.0 255.255.255.0 10.255.255.10
ip route 192.168.50.0 255.255.255.0 10.255.255.14

!


Spoke Config


interface Tunnel0
ip address 10.255.255.2 255.255.255.252
tunnel source Dialer1
tunnel destination ***HUB External IP Address***

ip mtu 1420
  tunnel path-mtu-discovery

crypto map tiptmap

!

ip route 192.168.0.0 255.255.0.0 10.255.255.1

Paolo Bevilacqua Thu, 02/11/2010 - 14:18

Seems correct, one would need an hand-on session to find some inaccuracy that may have slipped in.

The purporse of the multipoint tunnel is exactly to reduce all the bunch of addresses that lead to errors, and of course allow spoke-to'spoke traffic to not bounce off to hub.

Mark Rigby Thu, 02/11/2010 - 14:24

Got it working now, had the network statements for RIP wrong on the spokes. Thank you for your comments

Hub


interface Tunnel0
ip address 10.255.255.1 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 1.1.1.1
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel2
ip address 10.255.255.5 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 2.2.2.2
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel3
ip address 10.255.255.9 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 3.3.3.3
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel4
ip address 10.255.255.13 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 4.4.4.4
tunnel path-mtu-discovery
crypto map hqmap
!

router rip
version 2
network 10.0.0.0
network 192.168.0.0
no auto-summary



Spoke


interface Tunnel0
ip address 10.255.255.2 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 10.10.10.10
tunnel path-mtu-discovery
crypto map tiptmap

!

router rip
version 2
network 10.0.0.0
network 192.168.20.0
no auto-summary

Actions

This Discussion