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

[Paul Wouters]

On Thu, 12 Jan 2006, Roman Dergam wrote:

> > 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.


Then you must enable nat_traversal=yes on the laptop too.

> 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..

Ok

> 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

The other side should log the real error.

> 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

source port is not always 4500, due to NAT. You shouldn't use it in your rule.
But your problem is still getting phase 2 up. so check the server logs.

Paul