Make certain that if you have multiple tunnels on your gateway device that use the same tunnel source/ipsec profile, that you specify the "shared" keyword at the end of the tunnel protection statement.
-- Eric Cables On Wed, Nov 5, 2008 at 7:11 PM, Rakesh Hegde <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> 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 <[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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
