[c-nsp] ipsec over gre with nhrp
Rakesh Hegde
rakeshh at gmail.com
Wed Nov 5 22:11:57 EST 2008
Hello,
With the information you have provided, what I can see is that you are
trying IPSEC over GRE . I had come accross a similar issue where the router
used the GRE tunnel source interface to build the IPSEC tunnel even though I
had the tunnel interface as the local interface for the crypto map. This is
exactly what you are seeing here. I resloved the issue by learing a loopback
through the tunnel and using it as the IPSEC tunnel source/destination
points with the local loopback as the local interface for crypto map.
You also need to point any traffic to be encrypted, matching
the destination subnet in crypto acl, to the tunnel interface .
Thre is a simpler and prefered way of doing this using VTI interfaces . In
your case this is going to be GRE protection using IPSEC . It has worked
great for us.
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html
Hope this helps
-Rakesh
On Wed, Nov 5, 2008 at 4:04 PM, Bob Tinkelman <bob at tink.com> wrote:
> 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>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list