[Openswan Users] Linux client does not connect while Windows does
Andriy Lesyuk
s-andy at in.if.ua
Sat May 3 07:05:20 EDT 2008
Some updates..
> 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...
I have found somewhere that I need to be sure that both ends use the
same algo...
Windows connection has {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192
prf=oakley_sha group=modp2048} and Linux uses {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}. So I tried to
set the algo as follows:
conn nung
ike=3des-sha1
Tried also adding 3des-sha1-modp2048... None helps... :(
>
> 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... :(
Okey, this is not the issue any more - I needed to reboot... Now all
tests are OK.
Andriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080503/2e55cdcd/attachment-0001.html
More information about the Users
mailing list