cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
821
Views
4
Helpful
7
Replies

VPN 3030 to Cisco Router LAN to LAN, can only raise tunnel from router

grantlewis
Level 1
Level 1

I am unable to raise atunnel from inside my VPN 3030 Concentrator (IOS 3.5.2) The tunnel uses Ethernet 3 as the private side of the tunnel. Is there some sort of issue internally on the VPN 3030 that does not use the Ethernet 3 as a source IP? Once raised from the remote side, the tunnel passes and receives traffic and I can ping devices on the remote side from my private network, but I can not ping any remote device from inside the VPN 3030.

1 Accepted Solution

Accepted Solutions

Are you saying that you can now bring the tunnel up from something connected to the 10.255.0.0/24 network, but not from just pinging from the VPN3030 itself?

When you ping from the VPN3030 it'll automatically use the Private IP address I believe. The debug doesn't show us anything cause the first one you attached is where the DH group was mismatched. If you get past Phase 1 though, you'll see a debug message on the router similar to this one:

*Nov 26 08:51:37.901: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 204.74.161.161, remote= 216.34.168.148,

local_proxy= 10.1.215.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.255.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

In here you can see the remote_proxy is 10.255.0.0, which shows that the 3030 is using that network as the source subnet. If you try and ping from the 3030 again and run the debug, you'll probably see the 172.16.0.0 (the Private interface) as the remote_proxy.

Why does it matter that you can't bring up the tunnel from within the 3030 anyway? When would you want to do that?

View solution in original post

7 Replies 7

gfullage
Cisco Employee
Cisco Employee

There shouldn't be an issue with the External interface you're using. This is probably more that your access-list on the router and your Local and Remote Networks on the 3030 aren't the exact opposite of each other.

What errors do you see in the Event Log when you try bringing up the tunnel? If you enable "debug cry isa" and "debug cry ipsec" on the router, what do you see also, can you send that debug output in?

We found a Diffie-Hellman group mismatch.

Once this was corrected I was able to raise a tunnel from my attached router, but still not from within the VPN3030.

The 3030 private interface,

Ethernet 1 is 172.16.0.25

and the external interface,

Ethernet 3, is 10.255.0.2.

When I ping from inside the VPN 3030 how does the 3030 know to use a 10.255.0.0 source vice 172.16.0.25? Is there a debug setting on the 3030 that will show me the actual source address sent by a ping? Assuming this is the right direction to go.

Debug output follows (captured while attempting to ping from within 3030 and then from the router attached to the 3030)

VPN-7140-2#

*Nov 26 08:40:07.676: ISAKMP (0:0): received packet from 216.34.168.148 (N) NEW

SA

*Nov 26 08:40:07.676: ISAKMP: local port 500, remote port 500

*Nov 26 08:40:07.676: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Nov 26 08:40:07.676: ISAKMP (0:1): Old State = IKE_READY New State = IKE_R_MM1

*Nov 26 08:40:07.676: ISAKMP (0:1): processing SA payload. message ID = 0

*Nov 26 08:40:07.676: ISAKMP (0:1): found peer pre-shared key matching 216.34.16

8.148

*Nov 26 08:40:07.676: ISAKMP (0:1): Checking ISAKMP transform 1 against priority

1 policy

*Nov 26 08:40:07.676: ISAKMP: encryption 3DES-CBC

*Nov 26 08:40:07.676: ISAKMP: hash MD5

*Nov 26 08:40:07.676: ISAKMP: default group 2

*Nov 26 08:40:07.676: ISAKMP: auth pre-share

*Nov 26 08:40:07.676: ISAKMP: life type in seconds

*Nov 26 08:40:07.676: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

*Nov 26 08:40:07.676: ISAKMP (0:1): Diffie-Hellman group offered does not match

policy!

*Nov 26 08:40:07.680: ISAKMP (0:1): atts are not acceptable. Next payload is 0

*Nov 26 08:40:07.680: ISAKMP (0:1): Checking ISAKMP transform 1 against priority

2 policy

*Nov 26 08:40:07.680: ISAKMP: encryption 3DES-CBC

*Nov 26 08:40:07.680: ISAKMP: hash MD5

*Nov 26 08:40:07.680: ISAKMP: default group 2

*Nov 26 08:40:07.680: ISAKMP: auth pre-share

*Nov 26 08:40:07.680: ISAKMP: life type in seconds

*Nov 26 08:40:07.680: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

*Nov 26 08:40:07.680: ISAKMP (0:1): Encryption algorithm offered does not match

policy!

*Nov 26 08:40:07.680: ISAKMP (0:1): atts are not acceptable. Next payload is 0

*Nov 26 08:40:07.680: ISAKMP (0:1): Checking ISAKMP transform 1 against priority

65535 policy

*Nov 26 08:40:07.680: ISAKMP: encryption 3DES-CBC

*Nov 26 08:40:07.680: ISAKMP: hash MD5

*Nov 26 08:40:07.680: ISAKMP: default group 2

*Nov 26 08:40:07.680: ISAKMP: auth pre-share

*Nov 26 08:40:07.680: ISAKMP: life type in seconds

*Nov 26 08:40:07.680: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

*Nov 26 08:40:07.680: ISAKMP (0:1): Encryption algorithm offered does not match

policy!

*Nov 26 08:40:07.680: ISAKMP (0:1): atts are not acceptable. Next payload is 0

*Nov 26 08:40:07.680: ISAKMP (0:1): no offers accepted!

*Nov 26 08:40:07.680: ISAKMP (0:1): phase 1 SA not acceptable!

*Nov 26 08:40:07.680: ISAKMP (0:1): incrementing error counter on sa: construct_

fail_ag_init

*Nov 26 08:40:07.680: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_

MODE

*Nov 26 08:40:07.680: ISAKMP (0:1): Old State = IKE_R_MM1 New State = IKE_R_MM1

*Nov 26 08:40:07.680: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR

*Nov 26 08:40:07.680: ISAKMP (0:1): Old State = IKE_R_MM1 New State = IKE_READY

*Nov 26 08:40:15.676: ISAKMP (0:1): received packet from 216.34.168.148 (R) MM_N

O_STATE

*Nov 26 08:40:15.676: ISAKMP (0:1): phase 1 packet is a duplicate of a previous

packet.

*Nov 26 08:40:15.676: ISAKMP (0:1): retransmitting due to retransmit phase 1

*Nov 26 08:40:15.676: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE...

*Nov 26 08:40:16.176: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE...

*Nov 26 08:40:16.176: ISAKMP (0:1): incrementing error counter on sa: retransmit

phase 1

*Nov 26 08:40:16.176: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE

*Nov 26 08:40:16.176: ISAKMP (0:1): sending packet to 216.34.168.148 (R) MM_NO_S

TATE

*Nov 26 08:40:23.676: ISAKMP (0:1): received packet from 216.34.168.148 (R) MM_N

O_STATE

*Nov 26 08:40:23.676: ISAKMP (0:1): phase 1 packet is a duplicate of a previous

packet.

*Nov 26 08:40:23.676: ISAKMP (0:1): retransmitting due to retransmit phase 1

*Nov 26 08:40:23.676: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE...

*Nov 26 08:40:24.176: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE...

*Nov 26 08:40:24.176: ISAKMP (0:1): incrementing error counter on sa: retransmit

phase 1

*Nov 26 08:40:24.176: ISAKMP (0:1): no outgoing phase 1 packet to retransmit. MM

_NO_STATE

VPN-7140-2#

VPN-7140-2#

*Nov 26 08:51:37.433: ISAKMP (0:0): received packet from 216.34.168.148 (N) NEW

SA

*Nov 26 08:51:37.433: ISAKMP: local port 500, remote port 500

*Nov 26 08:51:37.433: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Nov 26 08:51:37.433: ISAKMP (0:1): Old State = IKE_READY New State = IKE_R_MM1

*Nov 26 08:51:37.433: ISAKMP (0:1): processing SA payload. message ID = 0

*Nov 26 08:51:37.433: ISAKMP (0:1): found peer pre-shared key matching 216.34.16

8.148

*Nov 26 08:51:37.433: ISAKMP (0:1): Checking ISAKMP transform 1 against priority

1 policy

*Nov 26 08:51:37.433: ISAKMP: encryption 3DES-CBC

*Nov 26 08:51:37.433: ISAKMP: hash MD5

*Nov 26 08:51:37.433: ISAKMP: default group 1

*Nov 26 08:51:37.437: ISAKMP: auth pre-share

*Nov 26 08:51:37.437: ISAKMP: life type in seconds

*Nov 26 08:51:37.437: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

*Nov 26 08:51:37.437: ISAKMP (0:1): atts are acceptable. Next payload is 0

*Nov 26 08:51:37.465: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_

MODE

*Nov 26 08:51:37.465: ISAKMP (0:1): Old State = IKE_R_MM1 New State = IKE_R_MM1

*Nov 26 08:51:37.465: ISAKMP (0:1): sending packet to 216.34.168.148 (R) MM_SA_S

ETUP

*Nov 26 08:51:37.465: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPL

ETE

*Nov 26 08:51:37.465: ISAKMP (0:1): Old State = IKE_R_MM1 New State = IKE_R_MM2

*Nov 26 08:51:37.533: ISAKMP (0:1): received packet from 216.34.168.148 (R) MM_S

A_SETUP

*Nov 26 08:51:37.533: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Nov 26 08:51:37.533: ISAKMP (0:1): Old State = IKE_R_MM2 New State = IKE_R_MM3

*Nov 26 08:51:37.533: ISAKMP (0:1): processing KE payload. message ID = 0

*Nov 26 08:51:37.565: ISAKMP (0:1): processing NONCE payload. message ID = 0

*Nov 26 08:51:37.565: ISAKMP (0:1): found peer pre-shared key matching 216.34.16

8.148

*Nov 26 08:51:37.609: ISAKMP (0:1): SKEYID state generated

*Nov 26 08:51:37.609: ISAKMP (0:1): processing vendor id payload

*Nov 26 08:51:37.609: ISAKMP (0:1): vendor ID is Unity

*Nov 26 08:51:37.609: ISAKMP (0:1): processing vendor id payload

*Nov 26 08:51:37.609: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major

*Nov 26 08:51:37.609: ISAKMP (0:1): vendor ID is XAUTH

*Nov 26 08:51:37.609: ISAKMP (0:1): processing vendor id payload

*Nov 26 08:51:37.609: ISAKMP (0:1): speaking to another IOS box!

*Nov 26 08:51:37.609: ISAKMP (0:1): processing vendor id payload

*Nov 26 08:51:37.609: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major

*Nov 26 08:51:37.609: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_

MODE

*Nov 26 08:51:37.609: ISAKMP (0:1): Old State = IKE_R_MM3 New State = IKE_R_MM3

*Nov 26 08:51:37.609: ISAKMP (0:1): sending packet to 216.34.168.148 (R) MM_KEY_

EXCH

*Nov 26 08:51:37.609: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPL

ETE

*Nov 26 08:51:37.609: ISAKMP (0:1): Old State = IKE_R_MM3 New State = IKE_R_MM4

*Nov 26 08:51:37.721: ISAKMP (0:1): received packet from 216.34.168.148 (R) MM_K

EY_EXCH

*Nov 26 08:51:37.721: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

*Nov 26 08:51:37.721: ISAKMP (0:1): Old State = IKE_R_MM4 New State = IKE_R_MM5

*Nov 26 08:51:37.721: ISAKMP (0:1): processing ID payload. message ID = 0

*Nov 26 08:51:37.721: ISAKMP (0:1): processing HASH payload. message ID = 0

*Nov 26 08:51:37.725: ISAKMP:received payload type 14

*Nov 26 08:51:37.725: ISAKMP (0:1): processing vendor id payload

*Nov 26 08:51:37.725: ISAKMP (0:1): vendor ID is DPD

*Nov 26 08:51:37.729: ISAKMP (0:1): SA has been authenticated with 216.34.168.14

8

*Nov 26 08:51:37.729: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_

MODE

*Nov 26 08:51:37.729: ISAKMP (0:1): Old State = IKE_R_MM5 New State = IKE_R_MM5

*Nov 26 08:51:37.729: ISAKMP (0:1): SA is doing pre-shared key authentication us

ing id type ID_IPV4_ADDR

*Nov 26 08:51:37.729: ISAKMP (1): ID payload

next-payload : 8

type : 1

protocol : 17

port : 500

length : 8

*Nov 26 08:51:37.729: ISAKMP (1): Total payload length: 12

*Nov 26 08:51:37.733: ISAKMP (0:1): sending packet to 216.34.168.148 (R) QM_IDLE

*Nov 26 08:51:37.733: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPL

ETE

*Nov 26 08:51:37.733: ISAKMP (0:1): Old State = IKE_R_MM5 New State = IKE_P1_CO

MPLETE

*Nov 26 08:51:37.737: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLE

TE

*Nov 26 08:51:37.737: ISAKMP (0:1): Old State = IKE_P1_COMPLETE New State = IKE

_P1_COMPLETE

*Nov 26 08:51:37.901: ISAKMP (0:1): received packet from 216.34.168.148 (R) QM_I

DLE

*Nov 26 08:51:37.901: ISAKMP (0:1): processing HASH payload. message ID = -10180

8608

*Nov 26 08:51:37.901: ISAKMP (0:1): processing SA payload. message ID = -1018086

08

*Nov 26 08:51:37.901: ISAKMP (0:1): Checking IPSec proposal 1

*Nov 26 08:51:37.901: ISAKMP: transform 1, ESP_3DES

*Nov 26 08:51:37.901: ISAKMP: attributes in transform:

*Nov 26 08:51:37.901: ISAKMP: SA life type in seconds

*Nov 26 08:51:37.901: ISAKMP: SA life duration (basic) of 28800

*Nov 26 08:51:37.901: ISAKMP: encaps is 1

*Nov 26 08:51:37.901: ISAKMP: authenticator is HMAC-MD5

*Nov 26 08:51:37.901: ISAKMP (0:1): atts are acceptable.

*Nov 26 08:51:37.901: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 204.74.161.161, remote= 216.34.168.148,

local_proxy= 10.1.215.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.255.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

*Nov 26 08:51:37.905: ISAKMP (0:1): processing NONCE payload. message ID = -1018

08608

*Nov 26 08:51:37.905: ISAKMP (0:1): processing ID payload. message ID = -1018086

08

*Nov 26 08:51:37.905: ISAKMP (0:1): processing ID payload. message ID = -1018086

08

*Nov 26 08:51:37.905: ISAKMP (0:1): processing NOTIFY INITIAL_CONTACT protocol 1

spi 0, message ID = -101808608, sa = 62D4964C

*Nov 26 08:51:37.905: ISAKMP (0:1): Process initial contact, bring down existing

phase 1 and 2 SA's with local 204.74.161.161 remote 216.34.168.148

*Nov 26 08:51:37.905: ISAKMP (0:1): asking for 1 spis from ipsec

*Nov 26 08:51:37.905: ISAKMP (0:1): Node -101808608, Input = IKE_MESG_FROM_PEER,

IKE_QM_EXCH

*Nov 26 08:51:37.905: ISAKMP (0:1): Old State = IKE_QM_READY New State = IKE_QM

_SPI_STARVE

*Nov 26 08:51:37.905: IPSEC(key_engine): got a queue event...

*Nov 26 08:51:37.905: IPSEC(key_engine): got a queue event...

*Nov 26 08:51:37.905: IPSEC(spi_response): getting spi 317805067 for SA

from 204.74.161.161 to 216.34.168.148 for prot 3

*Nov 26 08:51:37.905: ISAKMP: received ke message (2/1)

*Nov 26 08:51:38.157: ISAKMP (0:1): sending packet to 216.34.168.148 (R) QM_IDLE

*Nov 26 08:51:38.157: ISAKMP (0:1): Node -101808608, Input = IKE_MESG_FROM_IPSEC

, IKE_SPI_REPLY

*Nov 26 08:51:38.157: ISAKMP (0:1): Old State = IKE_QM_SPI_STARVE New State = I

KE_QM_R_QM2

*Nov 26 08:51:38.233: ISAKMP (0:1): received packet from 216.34.168.148 (R) QM_I

DLE

*Nov 26 08:51:38.285: ISAKMP (0:1): Creating IPSec SAs

*Nov 26 08:51:38.285: inbound SA from 216.34.168.148 to 204.74.161.161

(proxy 10.255.0.0 to 10.1.215.0)

*Nov 26 08:51:38.285: has spi 0x12F1520B and conn_id 2029 and flags 4

*Nov 26 08:51:38.285: lifetime of 28800 seconds

*Nov 26 08:51:38.285: outbound SA from 204.74.161.161 to 216.34.168.148

(proxy 10.1.215.0 to 10.255.0.0 )

*Nov 26 08:51:38.285: has spi 445126879 and conn_id 2030 and flags C

*Nov 26 08:51:38.285: lifetime of 28800 seconds

*Nov 26 08:51:38.285: ISAKMP (0:1): deleting node -101808608 error FALSE reason

"quick mode done (await()"

*Nov 26 08:51:38.285: ISAKMP (0:1): Node -101808608, Input = IKE_MESG_FROM_PEER,

IKE_QM_EXCH

*Nov 26 08:51:38.285: ISAKMP (0:1): Old State = IKE_QM_R_QM2 New State = IKE_QM

_PHASE2_COMPLETE

*Nov 26 08:51:38.285: IPSEC(key_engine): got a queue event...

*Nov 26 08:51:38.285: IPSEC(initialize_sas): ,

(key eng. msg.) INBOUND local= 204.74.161.161, remote= 216.34.168.148,

local_proxy= 10.1.215.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.255.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 28800s and 0kb,

spi= 0x12F1520B(317805067), conn_id= 2029, keysize= 0, flags= 0x4

*Nov 26 08:51:38.285: IPSEC(initialize_sas): ,

(key eng. msg.) OUTBOUND local= 204.74.161.161, remote= 216.34.168.148,

local_proxy= 10.1.215.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.255.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 28800s and 0kb,

spi= 0x1A8818DF(445126879), conn_id= 2030, keysize= 0, flags= 0xC

*Nov 26 08:51:38.285: IPSEC(create_sa): sa created,

(sa) sa_dest= 204.74.161.161, sa_prot= 50,

sa_spi= 0x12F1520B(317805067),

sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2029

*Nov 26 08:51:38.289: IPSEC(create_sa): sa created,

(sa) sa_dest= 216.34.168.148, sa_prot= 50,

sa_spi= 0x1A8818DF(445126879),

sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2030

VPN-7140-2#

Are you saying that you can now bring the tunnel up from something connected to the 10.255.0.0/24 network, but not from just pinging from the VPN3030 itself?

When you ping from the VPN3030 it'll automatically use the Private IP address I believe. The debug doesn't show us anything cause the first one you attached is where the DH group was mismatched. If you get past Phase 1 though, you'll see a debug message on the router similar to this one:

*Nov 26 08:51:37.901: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 204.74.161.161, remote= 216.34.168.148,

local_proxy= 10.1.215.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.255.0.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

In here you can see the remote_proxy is 10.255.0.0, which shows that the 3030 is using that network as the source subnet. If you try and ping from the 3030 again and run the debug, you'll probably see the 172.16.0.0 (the Private interface) as the remote_proxy.

Why does it matter that you can't bring up the tunnel from within the 3030 anyway? When would you want to do that?

My primary consideration is that I can bring the tunnel up from my side since we will run 200 stores through it (I do have a redundant 3030.)

I was concerned that something was still wrong since this was the only tunnel I could not bring up from inside the 3030.

I was using the External interface was to hide my private network from the other side (by attacing a NAT router) which also has the same network.

It appears the latest version of 3030 IOS will allow me to perform this function on the 3030, is that correct?

and, of course...thank you very much for your help, it did solve the problem

Iske
Level 1
Level 1

Same problem here with PIX to 17xx router, only the router

can raise tunnel. 36xx router to 17xx router no problems.

Iske

use show crypto isakmp policy to make sure all settings match.

Some settings, if default, do not show up in show run

Sind Sie in Frankfurt? I was stationed there.

i'm in munich.

the settings in sh cryp isakmp pol do match.

we're pinging the routers outside interface to monitor the lines.

if the tunnel is closed by the router, we cant't telnet and

ping the router from the inside.

i should show the configs ?!?

uli