[Openswan Users] Linux client does not connect while Windows does
Andriy Lesyuk
s-andy at in.if.ua
Sat May 3 05:35:18 EDT 2008
Hello,
Got back to you with another issue... :)
I have successfully set up Linux Openswan server and Windows XP client.
And the last one successfully connects to the server.
I have another Linux machine in the same network where Windows is. And,
currently, I can't make it working. :(
Okey... ipsec.conf:
version 2.0
config setup
nat_traversal=yes
conn nung
left=%defaultroute
leftrsasigkey=%cert
leftcert=/etc/ipsec.d/certs/s-andy-cert.pem
leftprotoport=17/1701
right=vpn.hostname
rightrsasigkey=%cert
rightca=%same
rightid="C=UA, ST=Ivano-Frankivsk, L=Ivano-Frankivsk, O=..., OU=...,
CN=..., E=...' # removed for confidence
rightprotoport=17/1701
authby=rsasig
pfs=no
rekey=no
keyingtries=3
auto=add
# Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
The logs when trying to connect:
andrix:~# ipsec auto --up nung
104 "nung" #1: STATE_MAIN_I1: initiate
003 "nung" #1: ignoring unknown Vendor ID payload [4f456c4c4f5d5264574e5244]
003 "nung" #1: received Vendor ID payload [Dead Peer Detection]
003 "nung" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "nung" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "nung" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i
am NATed
108 "nung" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "nung" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
117 "nung" #2: STATE_QUICK_I1: initiate
010 "nung" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "nung" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "nung" #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 "nung" #2: starting keying attempt 2 of at most 3, but releasing whack
The logs from the server:
May 3 12:13:32 base pluto[18567]: packet from 92.30.44.50:500: ignoring
unknown Vendor ID payload [4f45606c50487c5662707575]
May 3 12:13:32 base pluto[18567]: packet from 92.30.44.50:500: received
Vendor ID payload [Dead Peer Detection]
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
responding to Main Mode from unknown peer 92.30.44.50
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
STATE_MAIN_R1: sent MR1, expecting MI2
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
STATE_MAIN_R2: sent MR2, expecting MI3
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
Main mode peer ID is ID_DER_ASN1_DN: 'C=UA, ST=Ivano-Frankivsk,
L=Ivano-Frankivsk, O=..., OU=..., CN=..., E=...'
May 3 12:13:32 base pluto[18567]: "nung-server"[42] 92.30.44.50 #40:
switched from "nung-server" to "nung-server"
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
deleting connection "nung-server" instance with peer 92.30.44.50
{isakmp=#0/ipsec=#0}
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40: I
am sending my cert
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
cannot respond to IPsec SA request because no connection is known for
68.68.44.42[C=UA, ST=Ivano-Frankivsk, L=Ivano-Frankivsk, O=..., OU=...,
CN=..., E=...]:17/1701...92.30.44.50[C=UA, ST=Ivano-Frankivsk,
L=Ivano-Frankivsk, O=..., OU=..., CN=..., E=...]:17/1701===192.168.14.2/32
May 3 12:13:32 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
sending encrypted notification INVALID_ID_INFORMATION to 92.30.44.50:500
May 3 12:13:43 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0x23d79a89 (perhaps this is a duplicated packet)
May 3 12:13:43 base pluto[18567]: "nung-server"[43] 92.30.44.50 #40:
sending encrypted notification INVALID_MESSAGE_ID to 92.30.44.50:500
I have the feeling that something is wrong with NAT-T on the client
side... Sample logs for successfull Windows connection:
May 3 12:07:42 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
responding to Main Mode from unknown peer 92.30.44.50
May 3 12:07:42 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
May 3 12:07:42 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
STATE_MAIN_R1: sent MR1, expecting MI2
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03:
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
STATE_MAIN_R2: sent MR2, expecting MI3
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
Main mode peer ID is ID_DER_ASN1_DN: 'C=UA, ST=Ivano-Frankivsk
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38: I
am sending my cert
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
May 3 12:07:43 base pluto[18567]: | NAT-T: new mapping
92.30.44.50:500/60514)
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #38:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #39:
responding to Quick Mode {msgid:ba87b79c}
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #39:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #39:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #39:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
May 3 12:07:43 base pluto[18567]: "nung-server"[41] 92.30.44.50 #39:
STATE_QUICK_R2: IPsec SA established {ESP=>0xb40fab5b <0xde368f17
May 3 12:07:56 base pluto[18567]: "nung-server"[41] 92.30.44.50 #37:
Quick Mode I1 message is unacceptable because it uses a previously
May 3 12:07:56 base pluto[18567]: "nung-server"[41] 92.30.44.50 #37:
sending encrypted notification INVALID_MESSAGE_ID to 92.30.44.50:60381
I have mentioned that numbers (eg, #38, #39) for different parts of
connection for successful connection differ. And for the failure it
remains the same...
Here is ipsec verify:
andrix:~# 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.12/K2.6.22-3-k7 (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/send_redirects
or NETKEY will cause the sending of bogus ICMP redirects!
NETKEY detected, testing for disabled ICMP accept_redirects [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
or NETKEY will accept bogus ICMP redirects!
Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
ipsec showhostkey: no default key in "/etc/ipsec.secrets"
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [N/A]
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
I'm using built-in IPSec... I guess there should be NAT-T...
I have also two [FAILED] tests but I can't do anything with it: "echo 0
> /proc/sys/net/ipv4/conf/all/send_redirects" does not help... :(
Thanks,
Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080503/8e1d1b4c/attachment.html
More information about the Users
mailing list