You have to use tunnel protection profile instead. Get rid of the local-address, and put these in:
crypto isakmp policy 3000 encr aes 256 authentication pre-share group 5 crypto isakmp key test address 165.254.97.2 crypto isakmp keepalive 10 4 periodic ! ! crypto ipsec transform-set TEST esp-aes 256 esp-sha-hmac mode transport ! crypto ipsec profile foo set transform-set TEST set pfs group5 ! Int tun202 No crypto map tunnel protection ipsec profile foo Then route over the tunnel accordingly...intstead of using ACL to match traffic. Regards, Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net (blog) http://ccie-security.blogspot.com/ (e) [EMAIL PROTECTED] (aim/yahoo): luancnc -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Tinkelman Sent: Wednesday, November 05, 2008 5:05 PM To: [email protected] Subject: [c-nsp] ipsec over gre with nhrp 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 <[EMAIL PROTECTED]> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
