11-25-2002 11:12 AM - edited 02-21-2020 12:11 PM
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.
Solved! Go to Solution.
11-26-2002 03:21 PM
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?
11-25-2002 05:19 PM
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?
11-26-2002 02:12 PM
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#
11-26-2002 03:21 PM
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?
11-27-2002 06:30 AM
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
11-27-2002 04:20 AM
Same problem here with PIX to 17xx router, only the router
can raise tunnel. 36xx router to 17xx router no problems.
11-27-2002 09:05 AM
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.
12-03-2002 01:00 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide