[Openswan Users] Basic question: should I use Openswan?

[Roman Dergam]

Dne čtvrtek 12 leden 2006 02:16 Paul Wouters napsal(a):

Thanks for the reassuring reply. I haven't given up..

> Yes, you need to enable nat_traversal=yes on the server end, and then your
> laptop can connect from behind a NAT.

I tried this, once with both configured to use NAT traversal, then only the 
server. Now I have NAT traversal only on the server, as you suggested. I stil 
seem to have some probably very silly problem, which I shall describe below.

>
> If your laptop is Linux, you can setup an extremely simple connection based
> on two RSA keys. 

Yes, this is my situation. I generated the keys (on the server using an ipsec 
command, on the laptop through dpkg-reconfigure openswan). Both 2048.

There is a 2.4.0 on the laptop and compiled 2.4.4 on the server - both NOT 
using KLIPS. Both on 2.6 kernels..

> Check Jacco de Leeuw's pages and/or Nate Carlson's pages (or order the
> openswan book listed on www.openswan.org)

I looked at both pages you mentioned and it seems they are dealing with 
different cases from mine, using certs, subnets, etc.

My attempts to connect end with a strange result:

ipsec auto --up road
root at gunnar:/home/roman # /etc/init.d/ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec 2.4.0...
ipsec_setup: insmod /lib/modules/2.6.12-10-686/kernel/net/key/af_key.ko
ipsec_setup: insmod /lib/modules/2.6.12-10-686/kernel/net/ipv4/xfrm4_tunnel.ko
ipsec_setup: insmod /lib/modules/2.6.12-10-686/kernel/net/xfrm/xfrm_user.ko
root at gunnar:/home/roman # ipsec auto --up road
104 "road" #1: STATE_MAIN_I1: initiate
003 "road" #1: ignoring unknown Vendor ID payload [4f457a7d4646466667725f65]
003 "road" #1: received Vendor ID payload [Dead Peer Detection]
106 "road" #1: STATE_MAIN_I2: sent MI2, expecting MR2
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

I tried to allow all suggested services on the SERVER iptables - here are the 
lines:

-A INPUT -p udp -m udp --dport 500 -j RULE_5
-A OUTPUT -p udp --dport 500 --sport 500 -j ACCEPT
-A INPUT -p udp -m udp --sport 500 -j RULE_5
-A OUTPUT -p ESP -j ACCEPT
-A INPUT -p esp -j RULE_5
-A OUTPUT -p AH -j ACCEPT
-A INPUT -p ah -j RULE_5
-A INPUT -p udp -m udp --dport 4500 --sport 4500 -j RULE_5

The router on the LAPTOP side claims to have something that allows ESP and 
IKE, so I did not modify anything there. 

I am completely lost as to the possible causes of this. The LAPTOP is 
connected to a DSL router which is itself connected to a "4G" (in fact 3G) 
modem from IPWireless. I also tried without compression on both sides.

Looking inexpertly at the logs, there seems to be something strange about 
PAYLOAD, probably among many other things.

I have left the logs and barf files at http://intu.cz/swan - login intu and 
pass k0lom4z. What other useful data could I provide?

Thanks for any hints

Roman Dergam