[Openswan Users] INVALID_MESSAGE_ID in the Quick mode with NAT. Why?
yrff_ren
yrff_ren at 163.com
Thu Oct 30 00:55:55 EDT 2008
HELLO:
everyone!
I am trying to study the VPN by the openswan. Now the ipsec VPN passthrough the
NAT device make some trouble: INVALID_MESSAGE_ID in the Quick mode. Why? What
shall i do?
I do it by this way:
1: First,I constructed the VPN system by the openswan-2.4.7 on the CentOS-4.4 without NAT.
The IPsec SA established:
#ipsec auto --up road
104 "road" #1: STATE_MAIN_I1: initiate
003 "road" #1: received Vendor ID payload [Openswan (this version) 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
003 "road" #1: received Vendor ID payload [Dead Peer Detection]
003 "road" #1: received Vendor ID payload [RFC 3947] method set to=110
106 "road" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "road" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
108 "road" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "road" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
117 "road" #2: STATE_QUICK_I1: initiate
004 "road" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x62bdff15 <0xe3c1013e xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
2: Follow above step, constructed the VPN system by the openswan-2.4.7 on the CentOS-4.4 with NAT.
2.1 The VPN network topology with NAT are:
Note:the Router model is: H3C AR 18-21A,this product support the ipsec data passthrough the NAT.(http://www.h3c.com)
left network<--------->Router<-------------->laptop
eth1:192.168.3.33 LAN WAN eth0:192.168.0.22
eth1:192.168.1.9
2.2 Modify "/etc/ipsec.conf" on the left(192.168.3.33):
version 2.0
config setup
nat_traversal=yes
nhelpers=0
conn road
left=192.168.3.33
leftnexthop=%defaultroute
leftid=@laptop
leftrsasigkey=0sAQNgTnRnteuIwjhq/Lm9QdK60buLB3Ggdh8K+dGVHZ63zma3FP9LE2xp9xfysHI7i+7ey1D+YCWC2831h6jim7cJtIA5hI75h2NZtcl0MVxy
LqV++ryYiuceWgEMxG5Qr87nN+040kbZVmNrnJLSurZrrjNelqPuzJivlROcCYdeFHLWUh4PFbUDKmzpVoUy4hCokBnlhH3coasLBIe1+9G/eOz2mlEbjTi8E+0RS6iIqlfM
WdVMZv3QfRLDYGOMOVJRCXfJWVVJ3gzmj9vhA01ffQ/lfM2FyDPNOjzI384f6vFhkNS6M9Q1mr/v7GCPReHnPKiSs9LuY7mycgr610dFpta1K8AFJQYIPbLeEQma6GDj
right=192.168.0.22
rightsubnet=192.168.1.0/24
rightid=@vpnserver
rightrsasigkey=0sAQOMxeosF6RzqISPzFLzDI3winmxxBtr+UrFxGakqT1+q8ShGuADZc+iTvDPrJFSVraRVSfm/6yYfiCyWxmdrKQIDGTUQdzPu8PbeErEnny
d21asQsaHyQ3fG6VXZfgYiKTKIcDl1X3MP//0xZqNSh/UxysZ4xedWRrAX2A36PjSzCRhF9Te3k+VASURhkvTNV44zpQNm6kSx0Adm4guaQw6nPrYIVq5wkfLr9iwmXrMscH
rqcdvesDkevOQJrEYJ/PqB6PbwGsfsDrkEcTF1/gvvXh7cRCEEQ7MLlqHZHXT5TmsJCinVroCnmKQOtfMAsq7sNIqGU/Jm6O25oni95DE9J/TzAaJe5sNwkluLoBT4Q33
auto=add
include /etc/ipsec.d/examples/no_oe.conf
2.3 Modify "/etc/ipsec.conf" on the laptop(192.168.0.22):
version 2.0
config setup
nat_traversal=yes
nhelpers=0
conn road
left=192.168.0.22
leftid=@vpnserver
leftsubnet=192.168.1.0/24
leftrsasigkey=0sAQOMxeosF6RzqISPzFLzDI3winmxxBtr+UrFxGakqT1+q8ShGuADZc+iTvDPrJFSVraRVSfm/6yYfiCyWxmdrKQIDGTUQdzPu8PbeErEnnyd
21asQsaHyQ3fG6VXZfgYiKTKIcDl1X3MP//0xZqNSh/UxysZ4xedWRrAX2A36PjSzCRhF9Te3k+VASURhkvTNV44zpQNm6kSx0Adm4guaQw6nPrYIVq5wkfLr9iwmXrMscHr
qcdvesDkevOQJrEYJ/PqB6PbwGsfsDrkEcTF1/gvvXh7cRCEEQ7MLlqHZHXT5TmsJCinVroCnmKQOtfMAsq7sNIqGU/Jm6O25oni95DE9J/TzAaJe5sNwkluLoBT4Q33
rightnexthop=%defaultroute
right=%any
rightid=@laptop
rightrsasigkey=0sAQNgTnRnteuIwjhq/Lm9QdK60buLB3Ggdh8K+dGVHZ63zma3FP9LE2xp9xfysHI7i+7ey1D+YCWC2831h6jim7cJtIA5hI75h2NZtcl0MVx
yLqV++ryYiuceWgEMxG5Qr87nN+040kbZVmNrnJLSurZrrjNelqPuzJivlROcCYdeFHLWUh4PFbUDKmzpVoUy4hCokBnlhH3coasLBIe1+9G/eOz2mlEbjTi8E+0RS6iIqlf
MWdVMZv3QfRLDYGOMOVJRCXfJWVVJ3gzmj9vhA01ffQ/lfM2FyDPNOjzI384f6vFhkNS6M9Q1mr/v7GCPReHnPKiSs9LuY7mycgr610dFpta1K8AFJQYIPbLeEQma6GDj
auto=add
include /etc/ipsec.d/examples/no_oe.conf
2.4 Execute command on the left(192.168.3.33) and laptop(192.168.0.22):
#service ipsec restart
2.5 Execute command on the left(192.168.3.33):
#ipsec auto --up road
104 "road" #1: STATE_MAIN_I1: initiate
003 "road" #1: received Vendor ID payload [Openswan (this version) 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
003 "road" #1: received Vendor ID payload [Dead Peer Detection]
003 "road" #1: received Vendor ID payload [RFC 3947] method set to=110
106 "road" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "road" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
108 "road" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "road" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
117 "road" #2: STATE_QUICK_I1: initiate
010 "road" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "road" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "road" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "road" #2: starting keying attempt 2 of an unlimited number, but releasing whack
2.6 We will educe the ipsec data pass through the NAT failed from the above informations!!!Why??
2.7 The log file of ipsec on the left(192.168.3.33) are:
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: initiating Main Mode
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: received Vendor ID payload [Openswan (this version) 2.4.7 PLUTO_SENDS_VENDORID
PLUTO_USES_KEYRR]
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: received Vendor ID payload [Dead Peer Detection]
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: received Vendor ID payload [RFC 3947] method set to=110
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: STATE_MAIN_I2: sent MI2, expecting MR2
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: I did not send a certificate because I do not have one.
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: Main mode peer ID is ID_FQDN: '@vpnserver'
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc
_192 prf=oakley_md5 group=modp1536}
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: ignoring informational payload, type INVALID_ID_INFORMATION
Oct 29 15:33:00 beijing5000 pluto[3083]: "road" #1: received and ignored informational message
Oct 29 15:33:10 beijing5000 pluto[3083]: "road" #1: ignoring informational payload, type INVALID_MESSAGE_ID
Oct 29 15:33:10 beijing5000 pluto[3083]: "road" #1: received and ignored informational message
Oct 29 15:33:30 beijing5000 pluto[3083]: "road" #1: ignoring informational payload, type INVALID_MESSAGE_ID
Oct 29 15:33:30 beijing5000 pluto[3083]: "road" #1: received and ignored informational message
Oct 29 15:34:10 beijing5000 pluto[3083]: "road" #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable respons
e to our first Quick Mode message: perhaps peer likes no proposal
2.8 The log file of ipsec on the laptop(192.168.0.22) are:
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [Openswan (this version) 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [Dead Peer Detection]
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [RFC 3947] method set to=110
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Oct 29 15:25:41 shanghai5000 pluto[30593]: packet from 192.168.0.1:12291: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: responding to Main Mode from unknown peer 192.168.0.1
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: STATE_MAIN_R1: sent MR1, expecting MI2
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: STATE_MAIN_R2: sent MR2, expecting MI3
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: Main mode peer ID is ID_FQDN: '@laptop'
Oct 29 15:25:41 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: I did not send a certificate because I do not have one.
Oct 29 15:25:42 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Oct 29 15:25:42 shanghai5000 pluto[30593]: | NAT-T: new mapping 192.168.0.1:12291/12290)
Oct 29 15:25:42 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Oct 29 15:25:42 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: cannot respond to IPsec SA request because no connection is known for 192.168.1.0/24===192.168.0.22[@vpnserver]...192.168.0.1[@laptop]===192.168.3.33/32
Oct 29 15:25:42 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: sending encrypted notification INVALID_ID_INFORMATION to 192.168.0.1:12290
Oct 29 15:25:52 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x19529c28 (perhaps this is a duplicated packet)
Oct 29 15:25:52 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: sending encrypted notification INVALID_MESSAGE_ID to 192.168.0.1:12290
Oct 29 15:26:12 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x19529c28 (perhaps this is a duplicated packet)
Oct 29 15:26:12 shanghai5000 pluto[30593]: "road"[3] 192.168.0.1 #3: sending encrypted notification INVALID_MESSAGE_ID to 192.168.0.1:12290
2.9
#ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.7/K2.6.9-42.EL (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [OK]
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
Note:There is the capture dtat in accessories.
Thanks
yours: ruifengyang
email: yrff_ren at 163.com
2008/10/30
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20081030/4c458833/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capture ipsec data.cap
Type: application/octet-stream
Size: 5821 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20081030/4c458833/attachment-0001.obj
More information about the Users
mailing list