VPN tunnels?

BobSutan

BobSutan

[H]F Junkie
Joined
Apr 5, 2000
Messages
12,121
I cannot get a VPN tunnel interface to come up on two Cisco devices. One is a 6509 using a SPA card and VRF mode, the other is a 3825 with nothing special going on. I'm trying to establish a Virtual Tunnel Interface on the 6509 utilizing VRF and the SPA, but I'm at my wits end on this one. Google has failed. Cisco has failed. Cisco's rep I spoke with said it's possible, but I can't make it work. If I can't get this operational by the end of the week I need to find another job because I don't need this kind of frustration in my life.

Oh, and this is just a simple peer to peer VPN. The devices are directly connected as follows:

Loop1 - 6509 - FA1/0 ---[Tunnel]--- FA 1/0 - 3825 - Loop 1

FA1/0 on 6509: 192.168.1.1 /24
FA1/0 on 3825: 192.168.1.2 /24
Loop1 on 6509: 10.1.0.1/32
Loop1 on 3825: 10.2.0.1/32
Tunnel0 on 6509: 192.168.2.1/31
Tunnel0 on 3825: 192.168.2.2/31



vpn.jpg


Here is what I remember of the config off the top of my head:

6509

Code: 
access-list 110 permit ip 10.2.0.1 host 10.1.0.1 host
access-list 110 permit ip 10.1.0.1 host 10.2.0.1 host
access-list 110 permit icmp 10.2.0.1 host 10.1.0.1 host
access-list 110 permit icmp 10.1.0.1 host 10.2.0.1 host

Crypto isakmp policy 1
  encr aes
  authentication pre-share
  group 2

Crypto isakmp key vpntunnelkey address 0.0.0.0

crypto ipsec transform-set VPNTFSET esp-3des esp-sha-hmac
 
Crypto map VPNMAP ipsec-isakmp
  set peer 192.168.1.2
  set transform set VPNTFSET
  match address 110

interface Fa1/0
crypto map VPNMAP


3825

Code: 
access-list 110 permit ip 10.2.0.1 host 10.1.0.1 host
access-list 110 permit ip 10.1.0.1 host 10.2.0.1 host
access-list 110 permit icmp 10.2.0.1 host 10.1.0.1 host
access-list 110 permit icmp 10.1.0.1 host 10.2.0.1 host

Crypto isakmp policy 1
  encr aes
  authentication pre-share
  group 2

Crypto isakmp key vpntunnelkey address 0.0.0.0

crypto ipsec transform-set VPNTFSET esp-3des esp-sha-hmac
 
Crypto map VPNMAP ipsec-isakmp
  set peer 192.168.1.1
  set transform set VPNTFSET
  match address 110

interface Fa1/0
crypto map VPNMAP


**Edit**
Ignore these configs since I'm no longer using crypto maps at all since VTIs don't implement them.
 
im going to have to go with:

... that i would change the /31 to a /30. now granted, ive never used or have had reason or have ever thought 1 time about using a subnet that deliberately did not include a network-address and broadcast-address... but thats just me.

but ever time i set up a vpn endpoint, i always use a /30.

but if a /31 is proper for that type of then, then *shrug!* what the hell, ill use a /31 on my next one!
 
and also, both fa/0 interfaces appear to be on the same subnet, at both ends. again, unless you know something i dont... that wont route. change the 3825 to 192.168.2.2/24.
 
Sharaz Jek said:
and also, both fa/0 interfaces appear to be on the same subnet, at both ends. again, unless you know something i dont... that wont route. change the 3825 to 192.168.2.2/24.
Click to expand...

Hmm... I'll have to look into that. In the lab they're directly connected interfaces.

**Edit**
Found out being on the same subnet doesn't matter.
 
Lets try this instead..

Can someone post a config based on the information I provided that would establish an IPSec tunnel using tunnel interfaces? From there I should be able to port it into what I need.
 
#1 you don't have the crypto map applied to an interface. **oh snap, i didn't see it, my bad**
#2 your isakmp key is wrong, you need the other termination point IP address
#3 (this wont' stop your tunnels, but it's irritating...) your phase 2 acl's overlap, ICMP is part of IP, take the ICMP ACL lines out.
#4 Try pinging while sourcing your loopback interfaces, ping source loopback 1 192.168.x.x, or just use extended ping
#5 if it still doens't come up, do this:

debug crypto isakmp
term mon
*then*
clear crypto isakmp sa peer *peer address*
see what that spits out. BTW, I have a cheat sheet for routers, I don't need to use it anymore, but it's helped out.


crypto isakmp policy 10

encryption 3des (DES, 3DES, AES)

authentication pre-share

group 2

exit



crypto isakmp key (pre-shared key) address xxx.xxx.xxx.xxx(peer address)

crypto ipsec transform-set (NAME, usually the packet type-encryption type) esp-3des esp-md5-hmac

exit



access-list 101(extended list) permit ip xxx.source.xxx xxx.wildcard.xxx xxx.dest.xxx xxx.wildcard.xxx



crypto map OUTSIDE_MAP 10 ipsec-isakmp

match address 101(whatever acl)

set peer xxx.xxx.xxx.xxx

set transform-set (NAME, usually the packet type-encryption type)

exit

int (outisde if)

crypto map OUTSIDE_MAP

exit
 
oh, and one more thing, the "tunnel interface" doesn't exist for VPN connections, tunnel interfaces are for GRE. To make sure a VPN is up issue a: sh crypto isakmp sa command and look for QM_IDLE, then issue sh crypto ipsec sa and look for packet encaps and decaps. Oh, and make sure you have routes pointing out the right interfaces for the foreign traffic :-P
 
ok, Tunnel interfaces will still spit out GRE packets, you control traffic going into them with ip route statements. Route traffic into the tunnel interface, and GRE packets will come out and follow the route to the other endpoint. This looks like GRE over IPSEC with traffic shaping, very interesting. In that example, you wouldn't need to set the cryptomap on the outside interface, but use the statements:

tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI

there is no cryptomap with this VTI, instead there is an ipsec profile. Do you need the traffic shaping? If no, then a GRE tunnel over IPSEC is far easier to setup/explain on a forum. It looks like, from your config snippet, that you're trying to setup just a VPN tunnel, first. This VTI is a different animal and isn't close enough to a standard VPN tunnel to layer like I think you want to. It almost looks like you're trying to get the VPN tunnel up, then the GRE tunnel, then the traffic shaping, with VTI it looks like it's all or nothing.
 
Nope. Configured it verbatim per the document and it still didn't work. I don't know what's causing the tunnel interface to be stuck up/down. My gut tells me if I can get that frakker to come up my mission is accomplished.
 
Okay, I just put a router between them and it's the same thing. And yes I tried to ping. Also tried to ping sourcing the local loopback interface. What happens is the traffic is sent out the physical interface due to the default route. When I remove the default route traffic fails to pass indicating to me that the tunnel isn't working yet. Also, when the pings were working via the DR the sh crypto ipsec sa command indicated on one end decrypts were occurring and on the opposite end encrypts were occurring. However, no matter which end I pinged from the counters kept incrementing in the decrypt OR encrypt counter on the respective end. It wasn't like you'd think where on the device you ping FROM the encrypt counter would increment and vice versa. it was just one device was incrementing the encrypt coutner and the other device was constantly incrementing the decrypt counter regardless of which device I pinged from.
 
Well, if you get encaps and no decaps that means the traffic is going across the tunnel, but there's no corresponding route to get back.
 
So, it turns out on our version IOS [12.2(33)SHX] VRF mode must be enabled to do VTIs. That's part of why the tunnel interface wasn't functioning. So now I've got the SPA enabled and associated with the VTI. I was able to pass one ping across it before the ISAKMP association reset for some unknown reason. The tunnel on the end with the SPA is still up and looks solid, so now I'm trying to find out if there are any caveats with 12.3 which is running on the distant end device which is causing me problems now (Tunnel still isn't up on this one).

Note: even though VRF mode is enabled, I haven't yet associated the VTI with a VRF instance. That'll come later once it's all working the way it should.
 
ok, so it looks like VTI's must be associated with VRF's, that's pretty interesting, earlier IOS' wouldn't associate tunnel interfaces with VRF instances. So, I'd create a vrf instance, set the routes and NAT's if you need them and build the tunnel(s). debug isakmp, ipsec and icmp for testing.

I tried associating tunnel interfaces with a VRF a few months ago and failed, I didn't know about VTI's until now. Is there any particular reason you need this? I'd like to know what circumstances you'd need something like this, I mean, good luck and all, I tried it a while back and just went a different route, by using route maps, tunnel interfaces and an ipsec tunnel on a router one hop away from my VRF's.
 
Bob,

Did you ever find success in getting this configuration working with the SPA-IPSECs? I have been totally unable to get any version of the config options to work.

Thanks much for any input you might have

db
 
You must log in or register to reply here.
Back
Top