[c-nsp] ipsec over gre with nhrp
Bob Tinkelman
bob at tink.com
Wed Nov 5 17:04:32 EST 2008
I'm doing something that I thought I'd done before, but am
running into problems and need a sanity check.
I have 2 "customer site routers", each configured for main
access via T1 and backup Internet access via a cable-modem
service with a dynamic ip address.
They also have an ipsec vpn to route internal (192.168/16 and
10/8) nets between the two sites, using crypto maps on the
T1 serial ports in the standard way.
All that works.
I wanted to provide a backup to the ipsec VPN using the cable
modem ports, and proceeded as follows:
o I configured a multi-point tunnel with both customer sites
using nhrp to connect to one of my routers. [This works.
the routers can ping either other over the tunnel.]
This was done because otherwise the routers, each with a
dynamic ip address, would have trouble finding each other.
o I mimic'd the ipsec vpn on the T1 serial interfaces, building
a similar one on the tunnel interfaces. [This didn't work,
and it's pretty clear why.]
Here are the relevant portions of the config. [I'm willing to
share more, but wanted to keep this post managable.]
Interface housing the cable-modem:
| CT-gw#sho run int fa0/1
| Building configuration...
|
| Current configuration : 186 bytes
| !
| interface FastEthernet0/1
| description Cable modem connection
| ip address dhcp
| ip access-group from-cablemodem in
| ip nat outside
| ip virtual-reassembly
| duplex auto
| speed auto
| end
| CT-gw#
The address dhcp-assigned by the carrier:
| CT-gw#sho int fa0/1 | inc Internet address
| Internet address is 192.168.1.64/24
| CT-gw#
The tunnel interface:
| CT-gw#sho run int t202
| Building configuration...
|
| Current configuration : 729 bytes
| !
| interface Tunnel202
| description Dynamic multi-point ISPnet-customer tunnel
| bandwidth 1000
| ip address 69.48.189.23 255.255.255.0
| ip access-group from-world in
| no ip redirects
| ip mtu 1416
| ip nat inside
| ip nhrp authentication <redacted>
| ip nhrp map multicast 165.254.97.2
| ip nhrp map multicast 165.254.147.2
| ip nhrp map 69.48.189.1 165.254.97.2
| ip nhrp map 69.48.189.2 165.254.147.2
| ip nhrp network-id <redacted>
| ip nhrp holdtime 300
| ip nhrp nhs 69.48.189.1
| ip nhrp nhs 69.48.189.2
| ip nhrp server-only
| ip virtual-reassembly
| no ip route-cache cef
| no ip route-cache
| no ip mroute-cache
| delay 1000
| tunnel source FastEthernet0/1
| tunnel mode gre multipoint
| tunnel key <redacted>
| crypto map CLINTON-TU-202-MAP
| end
| CT-gw#
The tunnel is working:
| CT-gw#ping 69.48.189.24
|
| Type escape sequence to abort.
| Sending 5, 100-byte ICMP Echos to 69.48.189.24, timeout is 2 seconds:
| !!!!!
| Success rate is 100 percent (5/5), round-trip min/avg/max = 140/141/144 ms
| CT-gw#
| CT-gw#tr 69.48.189.24
|
| Type escape sequence to abort.
| Tracing the route to tu-202.fl-gw.cngrp.com (69.48.189.24)
|
| 1 tu-202.gw1.nycmnycz.ispnetinc.net (69.48.189.1) 28 msec 28 msec 28 msec
| 2 tu-202.fl-gw.cngrp.com (69.48.189.24) 136 msec * 136 msec
| CT-gw#
The crypto map is defined like this:
| CT-gw#sho run | begin crypto map CLINTON-TU-202-MAP
| crypto map CLINTON-TU-202-MAP local-address Tunnel202
| crypto map CLINTON-TU-202-MAP 1 ipsec-isakmp
| set peer 69.48.189.24
| set transform-set TRANSFORM-SET-FL
| match address CT-inside-to-FL-inside
| !
But it's not working.
It looks like it's using the wrong ip address for the "local
address" of the crypto map.
It's using the dhcp-assigned address of Fa0/1, when I'd thought
it should be using the address of Tu202.
| CT-gw#sho crypto map int t202
>>| Crypto Map: "CLINTON-TU-202-MAP" idb: Tunnel202 local address: 192.168.1.64
|
| Crypto Map "CLINTON-TU-202-MAP" 1 ipsec-isakmp
| Peer = 69.48.189.24
| Extended IP access list CT-inside-to-FL-inside
| access-list CT-inside-to-FL-inside permit ip 192.168.7.0 0.0.0.255 10.1.1.0 0.0.0.255
| Current peer: 69.48.189.24
| Security association lifetime: 4608000 kilobytes/3600 seconds
| PFS (Y/N): N
| Transform sets={
| TRANSFORM-SET-FL,
| }
| Interfaces using crypto map CLINTON-TU-202-MAP:
| Tunnel202
| CT-gw#
I think it's pretty clear that 192.168.1.64 won't cut it as one end
of the VPN.
The two customer sites are in CT and FL, both with their "cable modem
connections" actually being ATT DSL services. [Long story; don't ask.]
Amusingly, both show the leases with the same IP Addr and gateway, as in:
| CT-gw#sho dhcp lease
| Temp IP addr: 192.168.1.64 for peer on Interface: FastEthernet0/1
| Temp sub net mask: 255.255.255.0
| DHCP Lease server: 192.168.1.254, state: 3 Bound
| DHCP transaction id: 1FD4
| Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
| Temp default-gateway addr: 192.168.1.254
| Next timer fires after: 07:58:12
| Retry count: 0 Client-ID: cisco-0019.5550.5b41-Fa0/1
| Client-ID hex dump: 636973636F2D303031392E353535302E
| 356234312D4661302F31
| Hostname: CT-gw
| FL-gw#sho dhcp lease
| Temp IP addr: 192.168.1.64 for peer on Interface: FastEthernet0/1
| Temp sub net mask: 255.255.255.0
| DHCP Lease server: 192.168.1.254, state: 3 Bound
| DHCP transaction id: 1FD4
| Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
| Temp default-gateway addr: 192.168.1.254
| Next timer fires after: 07:57:26
| Retry count: 0 Client-ID: cisco-0019.5550.5c79-Fa0/1
| Client-ID hex dump: 636973636F2D303031392E353535302E
| 356337392D4661302F31
| Hostname: FL-gw
| FL-gw#
I don't think that's relevant.
I think the problem is that I need to get the crypto map to use the
69.48.189.23 (CT) and 69.48.189.24 (FL) addresses, not 192.168.1.*.
Thoughts?
--
Bob Tinkelman <bob at tink.com>
More information about the cisco-nsp
mailing list