VPN tunnels?

[Nutz]

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



Click for picture:
http://www.lan-slam.com/misc/networking/vpn.jpg

 

[jlazzaro]

please post the existing relevant configuration.

 

[Nutz]

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

6509

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

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.

 

[spidey07]

One quick comment - networking is a VERY difficult field and can be frustrating. But thankfully you can think it through, draw it out and see what is happening.

Just scanning over your config a lot is missing. Are you just trying to do a regular crypto/vpn tunnel? That's what it looks like.

 

[Nutz]

Originally posted by: spidey07
Just scanning over your config a lot is missing. Are you just trying to do a regular crypto/vpn tunnel? That's what it looks like.

For the moment, yes. Just a tunnel using a tunnel interface. What parts are missing? I'm trying to remember the config off the top of my head and I've gone through VRF+SPA+Tunnel, VRF+Tunnel w/o SPA, SPA+Tunnel w/o VRF, and every permutation thereof so don't be surprised if I'm mixing config elements. I'm pretty much as fried as can be right now.

And once the SPA+VRF+IPSec Tunnels are complete we get to include chassis to chassis SPA failover, which with VRF only supports stateless failover. And according to the document I read this afternoon stateless failover is actually an unsupported feature. Yay me! /sarcasm.

 

[spidey07]

Just go to cisco.com and then to the documentation for IOS VPN. I can't remember every single thing that is needed and just refer to the docs. Off the top of my head the crypto section is lacking.

 

[Nutz]

Originally posted by: spidey07
Just go to cisco.com and then to the documentation for IOS VPN. I can't remember every single thing that is needed and just refer to the docs. Off the top of my head the crypto section is lacking.

The crypto section looks good according to teh docs I have on hand if doing straight IPSec. However, when using the tunnel interfaces things go pear shaped. And Cisco's site is down at the moment so I'm SOL there for a while.

 

[Nutz]

Something I was just told is that it wont work because the Fa1/0 interfaces on the two devices are in the same subnet. Any truth to this?

 

[drebo]

I don't know that it's IMPOSSIBLE to make it work (I know that if you were to NAT accross the VPN you could make it work), but I would imagine that having them be different subnets would make it far easier. I've only ever done it that way.

 

[Nutz]

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.

 

[drebo]

I just found this: http://www.giac.org/certified_...acticals/gsec/3402.php .

It seems like it'd probably be a good walkthrough for you. I skimmed over it, it seems pretty detailed in its explanations and what not.

Edit:
I think this is actually what you're looking for: http://www.ciscoblog.com/archi...8/vpn_virtual_tun.html .

Explanations are lacking, but it's a GRE tunnel.

 

[Nutz]

The first one I already looked at and it's not utilizing tunnel interfaces. It's just a straight up old fashioned IPSec VPN in tunnel mode. I already did that last week. What I need is tunnel interfaces with Static VTIs.

And we can't do GRE. Not allowed for what we're trying to accomplish. Has to be VTI instead.

 

[drebo]

I was under the impression that "VTI" simply meant "Virtual Tunnel Interface".

GRE is simply the protocol that your two VTIs will use to talk to each other and simulate a point-to-point connection.

Edit:
Here's a more detailed version of the second one: http://www.cisco.com/en/US/tec...r0900aecd8029d629.html .

Same thing, same results.

 

[Nutz]

Originally posted by: drebo
I was under the impression that "VTI" simply meant "Virtual Tunnel Interface".

GRE is simply the protocol that your two VTIs will use to talk to each other and simulate a point-to-point connection.

Edit:
Here's a more detailed version of the second one: http://www.cisco.com/en/US/tec...r0900aecd8029d629.html .

Same thing, same results.

Hmm... that should do it then. Looks like what I did the other day, only slightly modified. I'll give it a try in the morning. Hell, I may just mock this up in the lab at the house tonight if I get a chance.

 

[Nutz]

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.

 

[drebo]

The IPSec tunnels will show down until you try to pass traffic.

Have you attempted to ping across?

 

[Nutz]

Originally posted by: drebo
The IPSec tunnels will show down until you try to pass traffic.

Have you attempted to ping across?

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.

 

[Nutz]

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.