[c-nsp] ipsec over gre with nhrp
Eric Cables
ecables at gmail.com
Thu Nov 6 09:46:39 EST 2008
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 <rakeshh at gmail.com> 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 <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/
> >
> _______________________________________________
> 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